I do a lot of work with node.js, and since the beginning I wrote my tests with Jasmine. Testing synchronous code has been extremely painless, like:
Most of my node code is written with callbacks, and I started to notice that using Jasmine, my async tests got pretty wild. A quick run-through will help explain how Jasmine is used, and why it works the way it does.
This approach lasted for a bit (and can still be used in Jasmine), but as programmers it just didn’t feel right there just had to be a better way. The next step Jasmine took to keep track of those callbacks involved two methods called
waitsFor, which share functional scope with each other. Here’s how you would write the above test using them:
If you don’t think that’s out of control, you can use your imagination to see how it looks with multiple asynchronous calls after one another, but it definitely works exactly as we’d hope.
Mocha is another framework, and mine of choice recently. It takes a different approach to testing async:
By passing a function (
done) into the test, you can track the end of the callback. If it hasn’t come back
done or failed an assertion in a certain time (default 2000 ms), the test fails.
This definitely feels much more natural, and the same mechanism is available in
Mocha supports a lot of different reporter styles, several paradigms including suites (TDD) and describe/it (BDD) styles, and has a pluggable assertion system (so you can use should.js, chaijs, etc).
Overall, definitely a big improvement to the clarity of my test suites. Hope you like it too!