It’s been two years since I posted Browser Unit Testing with Backbone, Mocha, Chai, and RequireJS and I still think that’s a good template for getting started if you’re starting a backbone application today. That talked about how to get the framework setup. Let’s talk now about what you could and should be testing.
I usually make sure my backbone applications have tests for:
- Any logic put into the models or collections. One strategy for backbone applications is to make fat models that contain lots of business logic. If that’s the case for your application, you’ll want good unit tests around those models.
- Basic view logic asserting that the core HTML you’re expecting to be rendered does so. Careful here that you only assert business logic and not design/styling.
- Any custom logic you might have created such as helper methods.
Model / Collection Assertions
If you put a lot of logic into your models or collections, you’ll want to have unit tests that specifically call these objects and test just their functionality in isolation. As with everything else when unit testing, the key to this is making sure that your models/collections are coded in such a way that they don’t have hard dependencies on other parts of your application.
For example, try not to do things like this:
View Logic Assertions
The most important thing in doing View assertions is that all of your views need to scope everything locally. The easiest one to get wrong is calling jQuery directly, instead of the locally scoped version of jQuery that backbone provides. For example:
this.$ instead of just
$, means that jQuery will be scoped to the current view. This not only helps backbone render the correct thing if you re-use selectors, but also helps us unit test without having to render the HTML to our spec runner.
In the gist below, I’ve created the guts of a sample application that assumes we’re trying to render posts to a page and how that would be unit tested.