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.