As we begin looking at the more complicated parts of our Backbone.js application, the process of isolating dependencies and testable behaviors can become an increasingly daunting task. To provide a little help in these areas, we will introduce Sinon.JS, which is a powerful test mock, stub, and spy library, in this chapter.
Sinon.JS allows us to artificially isolate Backbone.js components and test specific behaviors without interacting with the rest of the application. We will kick off our discussion on Sinon.JS with the following topics:
- Identifying some of the test limitations typically found in Backbone.js applications and testing scenarios that can benefit from test fakes
- Introducing the Sinon.JS test double and assertion library
- Learning how to examine application behavior with test spies
- Integrating the Sinon-Chai plugin into Chai for better test assertions
- Testing Backbone.js application components with test spies and other Sinon.JS utilities
Ideally, we would run insulated, fast, and consistent tests on all parts of a Backbone.js application without any modifications. In actuality, these goals encounter hurdles for at least some of the real code paths in a Backbone.js application.
We want to test Backbone.js components in isolation, but many components have dependencies on other parts of the application. We also want the tests to run quickly, but many parts of a Backbone.js application can slow things down, including the following:
- Network communication, such as persisting a model state to a remote backend datastore or a third party API
- Complex DOM manipulation with Backbone.js views and templates
- Timed events and DOM animations, especially those that deliberately wait (such as a slow jQuery fade)
Finally, many events and execution paths in a Backbone.js application are non-deterministic. For example, parallel network requests and user inputs can be received by the application in any order. To deal with these issues, we sometimes have to look beyond the actual program code and fake out some parts of the application during tests. For a deeper dive into some of the common testing limitations and motivations for faking, see Planning, Cheating and Faking Your Way Through JavaScript Tests by Christian Johansen (the creator of Sinon.JS) at http://msdn.microsoft.com/en-us/magazine/gg649850.aspx.
The modern techniques used to observe and/or replace program behaviors are collectively dubbed test doubles. The test doubles that we use in this book include:
- Spies: A test spy wraps a method under test and records inputs and outputs for later use. However, it does not change any of the underlying method functionality, as a spy is merely an observer. Test spies are useful in situations where we want to check how and when a given function is called from other parts of the application.
- Stubs: A test stub is a spy that additionally replaces the functionality of a method under test with a new behavior. Stubs are quite useful for test isolation. For example, when testing a single method that normally calls other functions, we can simply "stub out" the external function calls with a preprogrammed behavior. In this manner, tests can execute the specific code under test while faking out everything else.
- Mocks: Mocks are a combination of spies and stubs (observing function calls and replacing function behavior) that additionally verify expected function behavior during execution.
Note
For a good survey on test doubles, including approaches beyond the three we identified, see Exploring The Continuum Of Test Doubles by Mark Seeman (http://msdn.microsoft.com/en-us/magazine/cc163358.aspx) and Test Double Patterns web page by Gerard Meszaros (http://xunitpatterns.com/Test%20Double%20Patterns.html).