High level overview of some testing tools and how they can be used together.

1. Carson Banov
Testing and Tools

2. Testing and Tools
Mocha, Sinon, Chai

3. Why is testing important?

4. Unit testing: tests the smallest piece of code that can be tested.
These units are the building blocks of a piece of software.
Ex: A function works correctly, a class has some method and data, etc.
Unit tests are a basic guarantee that the code you have written is doing
what you want it to. "I know this code will always spit out X if it is passed
Y."
If you are developing as a team, it proves to the other coders that your
code is doing what you want it to. "This function is coded correctly and I
can prove it since these tests pass".
Allows you to build multiple 'units' together which helps in debugging. "I
know that this part of the code does this every time, so the problem is not
there."
unit testing

5. Functional testing tests a slice of functionality of the application.
A functional test guarantees a feature works.
Ex: A feature works correctly, some action triggers an appropriate
response, can touch multiple layers of an application.
Allows you to test that a series of units are working together correctly.
"The add new user feature works correctly."
Allows you to know when you have broken something important. "This
test broke, so my changes have changed how this works."
Allows you to map code to features. "The sign-up form is done,
because we have tests that cover a user's actions upon signing up."
Allows you to know that layers of an application are working or
interacting correctly. "I know the server is successfully talking to the
database because this test passes."
functional testing

6. Up to you.*
Before: write them as a planning exercise, and you know when
your feature/branch is done.
During: to figure out why it is not working, to track down bugs.
After: to test edge cases, provide proof your branch is working,
and to ensure future changes don't break this functionality.
* As long as your boss doesn’t tell you differently and you do
actually write them at some point.
when to write tests..

7. getting started
$ npm install mocha
$ npm install chai
$ npm install sinon
Can be used to test front-end javascript as well as a
server-side node application.

8. mocha
http://visionmedia.github.io/mocha/
“Mocha allows you to use any assertion library you
want, if it throws an error, it will work!”
This is where Chai comes in.

9. http://chaijs.com/
Essentially gives "expect", "should", and “assert”. Expect and should
keywords can be chained in ways that are quite readable.
var foo = 'bar'
foo.should.be.a('string');
foo.should.have.length(3);
expect(foo).to.be.a('string');
expect(foo).to.have.length(3);
assert.isString(foo, 'foo is a string');
Chai

10. back to mocha
A test suite is organized with series of functions using
the keyword "describe".
An individual test is a function specified using the
keyword "it".

11. more practically
Describe blocks should be well named.
We use “should …” convention to signify a test.

12. output
. . .
. . .

13. uh oh

14. async
Just add ‘done’.

15. test setup,
independence
before(), after(), beforeEach(),
afterEach()
Make sure tests are independent. You
can and should run each one on its own
and they would pass.

16. reusing data
Use describe blocks and setup hooks to
create desired data.

17. .skip and .only
Can be applied to individual tests or describe blocks.
Skip can be used while writing a test or series of tests
to unclutter the output or skip a test that is failing
because you haven’t gotten to that yet.
Less recommended: while first starting a code base
you can use skip as a placeholder for tests that you
need to write but the application doesn’t have those
parts implemented yet.
Only is great for repeatedly running just 1 test while
working on getting it to pass.
Used for local testing (don’t want any .only flags in
actual source).

18. .skip and .only
Be careful of letting these flags get into source.

19. using Sinon
http://sinonjs.org/
For testing only what you mean to test.
Provides methods for checking information about
function calls and spoofing what those function calls
return.

20. Spies: used to ‘wiretap’ a function.
For ensuring a function is being invoked with the right
argument(s) at the right time(s).
From Sinon: "original function will behave just as
normal."
spies

21. Stubs: used to replace a function with a custom
version.
Same power of inspection of a spy, but changes the
behavior of the function.
From Sinon: "the original function is not called".
Helps isolate a part of code to be tested. Can
specify different return value than the actual
function (test error handling, avoid making
unwanted network requests), even fine tune this
down to what it should return on successive calls to
the same function.
stubs

22. You can use the before, beforeEach, after,
afterEach hooks to persist and reset the Sinon
features.
synergy with mocha

23. Sinon has a built in feature for helping you keep
track of stubs, etc that you create: the sandbox.
synergy with mocha, Sinon sandbox

24. The sandbox can be used in beforeEach and
afterEach as well as nested.
synergy with mocha, Sinon sandbox

25. ‘Fixtures’ are often used to be imported as fake
data that can be returned or accessed by stubbed
methods. Can even be used to store fake
functions to use as those stubs.
You can use these on/with travis-ci, jenkins
Easy to configure a basic html page that runs the
tests as well as make a grunt command to run
them.
extra stuff

26. links
http://visionmedia.github.io/mocha/
http://sinonjs.org/
http://chaijs.com/
http://www.elijahmanor.com/unit-test-like-a-secret-agent-with-sinon-js/
http://blog.dylants.com/2013/06/21/jenkins-and-node/
https://travis-ci.org/
https://github.com/metaskills/mocha-phantomjs
http://www.fluencia.com/
http://www.spanishdict.com/
https://www.youtube.com/watch?v=TEAbWrdB9XU
http://backbone-testing.com/

27. thanks
Questions?