TDD, or Test Driven Development, is fairly well acknowledged to be a great idea. The general theory behind it is that you write your tests first, which will initially fail, and then you write just enough code to make the tests pass. Once the tests pass, the code is finished and you can move on to the next bit of functionality. There have been studies done that show that working this way drastically reduces the number of issues in the overall product.

And for some languages, this is all fantastic. You write the tests, the tests fail, you move on to the actual development.

And for yet other languages, this just doesn’t work at all. Specifically I’m thinking compiled, statically typed languages here. The problem with this scenario is, when you write your tests against non-existent types then you break the compilation of the test suite, which in turn breaks every test in the system. And that in turn means that until you’ve implemented at least enough for all of the tests to compile you can’t be sure that you’ve not broken anything else.

Read More

For a long time, one of the big problems I’ve had with NodeJS is that of Unit Testing. Specifically with the fact that, by definition, a Unit Test is testing a single unit in complete isolation of the rest of the world. In Node terms, a Unit would be a single Module.

Read More

I try to be a bit of a stickler when it comes to testing of my code. As such, I always like to make sure that I have support for Unit Testing in my projects from the very start, knowing full well that if not then the test quality just won’t be as good and the project will suffer as a result.

Testing of a project comes in various different flavours, of various different levels of importance.

• Unit Testing. This is testing every single Unit - Module in NodeJS terms - of a project in complete isolation. Everything that the module depends on should be replaced with Mocks that you have control over, so that you know exactly what is going on.
• Integration Testing. This is testing a group of units all together to make sure that the inter-operation between them is correct. The level that you do this at completely depends on the tests that you are doing. It might be simple testing 2 or 3 modules together, or it might be testing a full stack from API all the way down to a (mock) database. The key difference is that it is not testing one Unit in isolation, but testing the integration of several Units together, but isolated from everything outside of that set of Units
• Verification Testing. This is a less commonly used term, but it’s one that I use to mean testing of the entire project as a whole. It’s essentially Integration Testing, but where the collection of Units that you are Integration Testing is “all of them”. This can be very hard to get right, because ideally you need to test against a real database engine, and using a real browser. Often it’s just easier to do this level of testing by hand, but if you can automate it then you really should.

Read More