You've learned how to use a couple of different testing tools in this chapter, but what about when to use these tools?
When it comes to code testing, there's a metric known as "code coverage" that tells us the percentage of our code that is covered by tests. The first thought of a passionate architect starting a new project is that everything should be covered with tests, tests everywhere!
Realistically, there are things that we just don't need to test; as always, we should take a pragmatic approach. Configuration of components probably doesn't need to be tested; we don't need to test the return values from third-party code libraries; there are many examples.
Having said that, code coverage is a useful way to make sure that a certain level of testing is maintained in a project. For example, we might wish to have 90 percent test coverage of our model code and only 50 percent coverage on our controllers, which contain more boilerplate that doesn't need to be tested. The exact ratios will depend on the project, the developers, and indeed the architect.
Note
There are many code coverage tools for JavaScript, one of which is Istanbul. It provides a comprehensive set of features to check code coverage in a variety of ways and reports on the level of coverage in a range of formats. You can find this on GitHub at https://github.com/gotwarlost/Istanbul.
When a project is well covered by unit tests and integration tests are in place to make sure the user experience remains consistent, we're left with one part of the puzzle: when to run these tests?
Of course, a developer should be running the relevant tests for the section of code they're working on, but in reality, a full test suite can take a long time to execute. In such cases, we can make use of something called continuous integration (CI).
Note
Jenkins CI is an open source CI system (http://jenkins-ci.org/) and Circle CI (https://circleci.com/) is paid for, but with a free plan.
Whenever a developer pushes new code to the source control repository, a CI server grabs that code and runs the tests. This enables us to see when a developer has committed code that breaks the current build; it also gives us peace of mind that a successful CI build will be one that has passed our automated checks and is well on its way to production.