Before jumping into the testing waters, it makes sense to have a plan of what we should test and why. The term test plan is heavily overloaded with many potential interpretations as processes, literature, and practices have been prevalent and continuously evolving for decades. It is not surprising that modern test plans can range from casual, mostly ad-hoc practices to formal, 100-page documents requiring executive sign offs at various stages.
Note
For a more detailed discussion on the test plan practices applied to modern JavaScript applications, see the JavaScript Testing Beginner's Guide by Yuxian Eugene Liang (http://www.packtpub.com/javascript-testing-beginners-guide/book).
As Backbone.js applications are typically created in iterative development cycles, often without a lot of extra formality, we will take a fairly practical approach and create a test plan that simply identifies testing categories and applies them to the application under test. While an actual planning document or wiki is a best practice, it is not absolutely necessary. The overriding point is being able to identify what tests are appropriate for a given piece of code or feature during development.
We will focus on a few of the many overlapping concepts within the auspices of a test plan:
- Unit tests: Unit tests isolate parts of the application (individual functions, classes, and modules) to exercise. Some interpretations of a frontend unit test further require that the test executes quickly and without any I/O (network, disk, and so on).
- Partial integration tests: Integration tests typically involve testing the entire application stack—frontend, web server, backend datastore, and everything in between. We will not go that far in this book but will instead write frontend tests that combine multiple application parts (for example, collections and views) and verify that they are interacting correctly.
Unit tests take a narrow view and are often used by a developer to set forth a set of required behaviors for the small piece of code they are presently working on. Then, the code is developed to match up with the unit test assertions. Partial integration tests take a higher-level view, piecing together the application and checking that the individual components add up to a functional whole. In an exemplary Backbone.js application, a unit test might create a single model and test-only model methods. In contrast, a partial integration test might create a view with several subviews and a collection and verify that collection data changes modify the subview display.
Other concepts that we will not explicitly cover in this book, but that are worth becoming familiar with and integrating into the overall development and testing process, include:
- Full integration tests: Full integration tests incorporate the entire application (often seeded with known test data), exercise behavior as a user would through the frontend, and verify that the application responses propagate all the way from the backend to the user interface. For a Backbone.js application, this would entail pointing a browser window to the application's HTML page and running the application like a real user would.
- Regression tests: Regression tests isolate and expose reported bugs in an application. The tests are written first to verify that the bug is reproduced, after which the source code is fixed. The tests continue to be run as part of the overall test suite to ensure that the bug does not reappear.
- Usability tests: Usability testing encompasses many different forms and focuses on getting feedback that exposes portions of the application that need user interface or user experience improvements.
- Performance/load tests: Performance tests verify that the application maintains minimum response times for given use cases. Load testing checks that the application can still meet performance goals when different parts of the program are stressed.
- Acceptance tests: Acceptance tests form the criteria by which a customer can verify that the application meets its requirements. A suite of acceptance tests can include any of the categories of tests mentioned previously.
Now that we have had a brief introduction of these various testing concepts, we will develop an informal test plan for our Backbone.js application. We will examine the various parts of our Backbone.js application and identify what needs to be tested, what type of tests we should apply, and the behavior that we need to verify in the application. For the parts of an application that are still in development or in the early design phases, we'll go through the same exercises, just with a focus on the behaviors we expect the application to exhibit once it has been developed.