In this chapter, we are going to explore the topic of testing in Node and hapi. We will look at writing a simple test using hapi's test runner lab, testing hapi applications, techniques to make testing easier, and finally, achieving the all-important 100% code coverage.
Testing is often a contentious issue when it comes to development. There are different attitudes towards its importance and relevance in the development cycle. Some developers believe in a Test-driven Development model, where tests should be written first. Others write tests while developing or wait till development is complete, then try and reach 100% code coverage with their tests. Unfortunately, in most cases, many don't bother with any at all, usually with what I believe to be as the naive view that "there isn't enough time to write tests".
Most of my career has actually been spent with the latter point of view, but working with hapi and seeing the benefits by focusing on testing throughout the ecosystem has shown me the light in this regard. In the hapi ecosystem, testing and 100% code coverage are paramount, and no code change to any module within the ecosystem will be accepted if the change isn't accompanied by the tests required to keep code coverage at 100%—a rule I now apply to all my own modules on npm.
You might ask why is testing and 100% coverage so important? What are its advantages? And if testing is so important, why is it often overlooked? Let's explore those questions now, starting with the latter.
In my experience, most development comes from two motivations: employment or recreation. There are others such as creating open source software (like hapi), research, and the like, but most of them fall under the aforementioned two categories. The motivation behind both categories is usually result-focused; when the motivation is employment, we aim to generate a monetary value from the code that we write. In case it is recreational, we are often exploring a new technology and just want to build something for a demo or to learn the inner workings of a new framework or library. It's easy to see how writing tests doesn't fit into either category.
In case of development for employment, tests aren't a sellable feature of software and are expensive. They take a lot of time and money to design, write, maintain, run, and keep up-to-date with best practices. Often, the size of a testing codebase will be larger than that of the codebase it is testing. The thought process here is usually: what's the return on investment? When we've deadlines to meet, why would time be spent on writing and maintaining code that can't monetized. So usually, the thought process is "manual testing is enough".
With recreational development, our focus is often on doing something quickly, learning that new language or framework, or quickly prototyping that app we want to demonstrate. We don't have the time to write tests. Tests aren't fun either, why write them?
Unfortunately, the downside to not writing tests is that we become better at developing code and worse at testing. I believe a lack of emphasis on testing makes us inefficient and less productive developers. Why? I'll explain this is the next section.