Having finished discussing the substantive techniques for testing Backbone.js applications, we will now look into various means of automating our test infrastructure. The ability to programmatically run our test collection enables new and exciting use cases beyond a single developer manually running a test driver page during development. In this chapter we will explore the following automation and development topics:
- Surveying scenarios and motivations for automating our test infrastructure
- Investigating different approaches for programmatically running a Backbone.js application test suite
- Introducing PhantomJS and adapter tools for frontend testing
- Integrating our existing test infrastructure into the PhantomJS environment
- Concluding our discussion on the principles and practices of Backbone.js application testing with suggestions and resources for the next steps after finishing this book
Up to this point, our test development workflow has comprised writing test suites, adding them to a test driver page, and firing up the test page in a web browser on a development computer. However, test infrastructures can be used in far more scenarios than just manually running web reports. Examining the ensuing use cases, we will see how automatically running our test collection in arbitrary environments (for example, from a command line or build script, and possibly without a web browser) has enormous potential for the application development process.
In collaborative software development, problems can arise when engineers develop code separately that they later merge into a common code base. Unforeseen interactions between the changes can cause integration errors, breaking the overall application.
One mitigation approach for such errors is continuous integration, which relies extensively on automated testing. Continuous integration aggregates and tests application code to detect integration errors early and automatically. For an in-depth introduction on the topic, see Continuous Integration by Martin Fowler at http://martinfowler.com/articles/continuousIntegration.html.
The process of continuous integration is typically implemented using a dedicated server that incrementally gathers code changes, creates a clean application environment, runs build commands, and acts on the command outputs. For instance, let's say we have a Node.js application stored on GitHub. A continuous integration server could download code changes from GitHub, create a new build directory for the application, install package dependencies (for example, npm install), and run the tests (for example, npm test). If any of the tests fail, the server will notify the developer(s) responsible for the changes. Some prevalent continuous integration servers include Jenkins (http://jenkins-ci.org/) and Travis (https://travis-ci.org/).
A continuous deployment server is an enhancement of a continuous integration server that additionally deploys code to a live application environment (for example, production) if all the tests pass. It relies on automated tests to validate the entire application, so that code changes can be pushed out as fast as possible while retaining at least some semblance of quality assurance. The article Why Continuous Deployment? by Eric Ries at http://www.startuplessonslearned.com/2009/06/why-continuous-deployment.html is a good starting point for the motivations and practices behind continuous deployment.
Test automation enables many other useful applications. For example, development utilities called watchers or guards check code periodically for modifications and perform further actions when the files change. Watchers are regularly used on a development machine to automatically run tests and display alerts when code changes have broken one or more tests, so that developers can discover errors quickly and effortlessly.
Cross-browser testing is another area made easier through automation. While a programmer can manually run a test collection on many different target browsers, this is often time consuming, error prone, and boring. Fortunately, there are testing tools that can programmatically run tests on a number of arbitrary web browsers without human interaction.