- Doing stuff in the terminal is not scary at all
- npm is not only for getting packages
- Package.json is a mighty tool
- Git is not that hard, but I need to refresh my knowledge
- Callback function is cool stuff, and I even know how to write them
- mocha is cool both as framework and test runner - this post
- Should is a nice way to do asserts
- monk is an easy way to access mongo
- Express is best without generators
- supertest is a nice way to test an api
The two frameworks that are mentioned the most is jasmine and mocha. The way you write your tests in these frameworks are very much alike and the main difference is in how you run them. Jasmine is executed in a browser (as I understand it) and mocha is run at the terminal, but could be run in the browser too. I like the terminal, as you know.
Ok, there’s also test runners that isn’t a test framework… like Karma, and probably some more. These tools run any kind of tests (like jasmine, mocha or what have you). At first I tried to use this but when I realised that mocha comes with a test runner that suited all my needs up to now. And it was a much easier set up.
I’ve got stuck on mocha since I think the runner is very capable and the syntax is nice. Finally it was really easy to get started with, where there are few more pieces to puzzle together with Jasmine. Mocha is installed with ease, just like any node package, by
npm install mocha.
If you add the “-g” flag you’ll be able to run mocha tests in any directory. Remember, from my package.json-post, that you should include it in your local node_modules as well. In my opinion, once you have pulled down a project you should just have to go “npm install” and then be able to run it. No extra steps should be required.
The syntax of a mocha (and to be honest most JavasScript testing frameworks I’ve seen) resembles the Ruby tool RSpec. It’s a pretty straight forward API and for most of your needs you only need to care about 3 to 4 functions: describe(description, func) – this is the top level function of your tests. It takes a string description of the thing that you are describing (or testing if you have your tester hat on) and then a function with it-statements. This would be the test fixture in xUnit frameworks.
- These can be nested and we’ll get back to how to write this without going crazy.
it(description, func) – this is your actual specifications that poke your system and does tests. The test-methods if you want to compare it with xUnit style of tests.
beforeeach(func)and before(func) – this is methods that is executed before… Before what you might ask, well that has to do with where you place them. If you place them inside a describe-block (which is the most common place I use them) then the beforeEach-block is run before each it-statement. It can also be place outside any describe and will then be run for all the describe’s. It suitable for setup of your system under test, for example
aftereach(func) and after(func) – and there´s a tear down version of course. The same rules goes for that.
Mocha is much bigger than this, but with these simple api I’ve managed most my testing needs so far.
The done() parameter
One thing that really messed things up for me in the beginning was when I left out or didn’t handle the done-parameter to my it-statements. I think (and will hopefully be corrected on this if I’m wrong) that mocha runs it’s test asynchronously, as many things are with Node. This means that we need to inform mocha on when our test code is done, so that mocha can pick it up again and process the next test.
This sounds complicated but in reality just comes as a parameter to the functions in our describe, before/after and it-statements. That parameter, done, is a function that we call when our test is complete. Like this:
Failing to call the done-function will render a timeout exception and you’ll faced with an error message like this: