Modern web development is witnessing a JavaScript renaissance, with the expanding popularity of frontend-driven, single-page, and real-time web applications. Leading and facilitating the charge are a number of JavaScript web frameworks that enable developers to sensibly organize frontend web applications into modular and convention-driven components. As more logic and functionality is pushed from the server to the browser, these frameworks are increasingly critical in maintaining single-page application state, avoiding unstructured and ad hoc "spaghetti" code, and providing abstractions and functionality for commonly encountered development situations.
This book will focus on one such framework—Backbone.js (http://backbonejs.org/)—that stands out from the crowd with a well-balanced feature set including small footprint size, solid core abstractions, and significant community support. Backbone.js provides a minimum set of useful interfaces (for example, models, collections, routers, and views) for application development while maintaining an enormous amount of flexibility with pluggable template engines, extensible events for cross-component communication, and a generally agnostic approach to code interaction and patterns. The framework is used at scale in applications for organizations such as USA Today, LinkedIn, Hulu, Foursquare, Disqus, and many others. Essentially, Backbone.js provides practical tools for data-driven, client-heavy web application development without getting too much in the way.
However, this evolving world of frontend development is scattered with many potential stumbling blocks. More specifically, while the theoretical application possibilities with modern JavaScript frameworks such as Backbone.js are endless, one of the most critical issues looming over rapid application development in this sphere is software quality and reliability.
JavaScript web applications are already notoriously difficult to verify and test: asynchronous DOM events and data requests are subject to timing issues and spurious failures, display behavior is difficult to isolate from application logic, and test suites depend on/interact with a specific browser. Frontend frameworks such as Backbone.js add another level of complexity with additional interfaces that need to be isolated and tested, large numbers of various small components interacting concurrently, and event logic propagating throughout application layers. Moreover, the implementation agnostic paradigm of Backbone.js produces wildly varying application code bases, making test guidelines and heuristics something of a moving target.
In this book, we will tackle the challenge of testing Backbone.js applications by identifying the parts of an application to be tested, asserting correct behavior of various components, and verifying that the program works as intended as an integrated whole. Kicking things off in this chapter, we will introduce a basic test infrastructure in the following parts:
- Designing a repository structure in which to develop Backbone.js applications and tests
- Getting the Mocha, Chai, and Sinon.JS test libraries
- Setting up and writing our first tests
- Running and assessing test results with the Mocha test reporter
We assume that the reader is already comfortable with JavaScript web application development and familiar with Backbone.js and its usual complements—Underscore.js (http://underscorejs.org/) and jQuery (http://jquery.com/). All other libraries and technologies will be properly introduced as they are used throughout this book.
Setting up a test infrastructure first requires a plan as to where all the parts and pieces will go. We will start with a simple directory structure for a code repository as follows:
app/
index.html
css/
js/
app/
lib/
test/
test.html
js/
lib/
spec/The app/index.html file contains the web application, while test/test.html provides the test driver page. Application and test libraries are respectively contained in the app/js/ and test/js/ directories.
The Backbone.js application and component files (models, views, routers, and so on) are placed in app/js/app/, which may look something like the following:
app/js/app/
app.js
models/
model-a.js
...
views/
view-a.js
...
...The core application libraries are stored in app/js/lib/, which should include the libraries needed to drive the actual application:
app/js/lib/ backbone.js jquery.js underscore.js ...
The test libraries and suites get a separate directory, test/js/, which isolates the test code from the application to avoid inadvertently introducing application dependencies on test functions or libraries:
test/js/
lib/
mocha.js
mocha.css
chai.js
sinon.js
spec/
first.spec.js
second.spec.js
...Now that we have an abstract application and a test layout, we need to fill in all the pieces and populate directories with libraries, web pages, and test files.