A Backbone.js application is used as a cohesive whole by end users, and wherever possible, we should have the test infrastructure verify overall application functionality and behaviors that cut across single Backbone.js components.
While unit tests are a staple of modern software development, we must metaphorically move from unit-testing trees to the forest of partial integration tests to ensure that at least some pieces of the application work together harmoniously and reliably. In practice, this just means varying the degree to which we mock or remove component dependencies in the tests we discussed previously.
Integration tests can interact with application parts in many ways, including:
All Backbone.js classes extend the Backbone.Events
base class and typically emit and consume events as a first-order means of communication. We will want to test that our application components trigger correctly and react to various expected events during the application's execution. We will often leverage tools, such as spies, stubs, and mocks, to exercise the event logic we want to test while not actually affecting other application states.
We will also need to carefully craft our test code to properly set up and tear down the test environment so that we can make reasonable assumptions about the starting event listener state in each test. For example, if multiple tests add custom listeners to a shared object without cleaning up, other tests could spuriously fail due to listener callback interaction.
The event behaviors that we will want to test across all our Backbone.js components include whether:
3.19.63.106