If you search the web for articles on code coverage and mocha, you are likely to find a lot of articles about setting up jscoverage and using a NODE_ENV conditional to include instrumented test files. You can go down that road, like I did, but I am here to save you time.

If you look at the tests for a Node module, you should see that for every export, there is an associated test. But if you look at the Node module source itself, you may see dozens of support functions that aren’t exported.

You can make an argument that the public interface is all that needs to be tested, but I am inclined to think that this is not true. It is not hard to find very sophisticated modules that only export one or two methods. If we don’t have tests on some of those internal functions, it just means that our debugging process is going to be that much harder.

To remedy this, I have started to adopt the practice of conditionally exporting methods for testing purposes.

Recently I had to write some code to test if a widget was receiving the custom style that it was supposed to be receiving. Imagine a single page app where some view receives user configured style. How do you test that?

You might think that a headless browser such as zombie would give you the ability to inspect style, but you’d be mistaken. Zombie is headless, so it doesn’t actually do any visual rendering. That means it doesn’t calculate css properties.

I like to use Mocha and superagent to test my controller actions. I like the syntax of Mocha. It feels like rspec, and rspec is where I cut my teeth. Superagent is a tiny little http request library. It’s not a browser. It’s more akin to curl. The combination of Mocha and superagent allows me to write tests quickly and without a whole lot of fuss.