Throughout this book we've been pushing the idea that JavaScript is no longer a toy language with which we can't do useful things. Real world software is being written in JavaScript right now and the percentage of applications using JavaScript is only likely to grow over the next decade.
With real software comes concerns about correctness. Manually testing software is painful and, weirdly, error-prone. It is far cheaper and easier to produce unit and integration tests that run automatically and test various aspects of the application.
There are countless tools available for testing JavaScript, from test runners to testing frameworks; the ecosystem is a rich one. We'll try to maintain a more or less tool-agnostic approach to testing in this chapter. This book does not concern itself with which framework is the best or friendliest. There are overarching patterns that are common to testing as a whole. It is those that we'll examine. We will touch on some specific tools but only as a shortcut to having to write all our own testing tools.
In this chapter we'll look at the following topics:
- Fake objects
- Monkey patching
- Interacting with the user interface
We computer programmers are, as a rule, highly analytical people. This means that we're always striving to categorize and understand concepts. This has led to our developing some very interesting global techniques that can be applied outside computer programming. For instance, agile development has applications in general society but can trace its roots back to computing. One might even argue that the idea of patterns owes much of its popularity to it being used by computer programmers in other walks of life.
This desire to categorize has led to the concept of testing code being divided up into a number of different types of tests. I've seen as many as eight different categories of tests from unit tests, right the way up to workflow tests and GUI tests. This is, perhaps, an overkill. It is much more common to think about having three different categories of test: unit, integration, and user interface:
Unit tests form the foundation of the pyramid. They are the most numerous, the easiest to write, and the most granular in the errors they give. An error in a unit test will allow you to find the individual method that has an error in it. As we move up the pyramid, the number of tests falls along with the granularity while the complexity of each test increases. At a higher level, when a test fails we might only be able to say: "There is an issue with adding an order to the system".