Extol the testing pyramid.
If your code has logic, it should have unit tests. As seen in the pyramid, unit tests should comprise the majority of your tests. Why? Unit tests can be executed quickly, they can be easily automated, they're maintainable and they promote good practices by requiring your code to be written in concise, modular chunks.
A unit test verifies that a single discrete piece of your codebase works as expected. That "piece" could be a JavaScript function, a CommonJS/AMD module or some other unit of functionality. It's vaguely defined but don't let that scare you. Start by choosing one of the test frameworks below and writing tests for individual JavaScript methods. There are many guides about writing JavaScript unit tests that serve as great introductions. At CFPB we like to separate our JavaScript into discrete npm modules. This makes testing easier because each module includes self-contained tests.
- Mocha is a slick, simple testing framework for Node and browser JavaScript with asynchronous support and a slew of reporters, including TAP output.
- Jasmine shares basic semantics with Mocha, but also includes lots of nice assertion helpers, object spies, and async support.
- Tape is a TAP-producing test harness for Node with great asynchronous support. Check out the Testling tape guide.
Check out 18f's excellent testing cookbook for more best practices.
The goal is to have all of your code covered by unit tests. Tools known as code coverage reporters will tell you what percentage of your codebase is covered by tests. Owning A Home uses grunt-mocha-istanbul to integrate istanbul with their Mocha tests. When OAH tests are run using grunt test, Istanbul prints the coverage % to the command line and generates an interactive HTML code coverage report in test/coverage.
Integration tests test the points at which your front-end JavaScript communicates with your project's back-end. These tests run slower than unit tests because they interact with an external environment. When building single page applications, integration tests usually come in the form of API tests.
Owning A Home uses Selenium and Behave to execute feature files that verify their API is working as expected. If the OAH API starts returning data in a format unexpected by the front-end, these integration tests will immediately start failing, alerting developers to the problem. Integration tests are also useful for detecting down or slow communication channels.
When building browser-based applications, systems tests are browser (otherwise known as GUI) tests. They verify that the front-end code operates as expected in environments similar to the end-users'. They are slow and expensive to write and maintain. They break easily when the GUI is modified. But they are an incredibly important method of ensuring your application is operating correctly.
They are often written in languages that can be understood by non-developers, traditionally business analysts. Owning A Home's browser tests are written in Gherkin. Most CFPB projects use behave for browser testing. After installing it, check out their tutorial to learn how to use it. Check out OAH's browser tests for a comprehensive example.