Why write your tests in something else than JavaScript when it's a JavaScript app? We already wrote a lot of unit tests in JavaScript, and our integration tests grew gradually from them, so we didn't feel we needed to add another layer of abstraction on top of regular JS.

You can write your browser automation tests in JavaScript. See WebDriverJS, Jelly, or PhantomJS.

* http://code.google.com/p/selenium/wiki/WebDriverJs

* http://jelly.io

* http://phantomjs.org/

Jasmine is used for unit testing and you should mock dependencies like faking XHR requests, whereas with Capybara/Selenium you do acceptance tests to test the frontend/backend integration.

Another aspect related to this point is that we have a slow backend system and we wanted our JavaScript tests to be blazingly fast, also the integration tests. I hate waiting for tests. Now I can run ours all the time because they don't use any time at all (well, okey, they take a second ...).

Also, by using the procedure described in the post you don't need to have a DOM set up. Note that the view has no knowledge of where it is supposed to be rendered on the page. It could be passed into PersonsView with an el option: new PersonsView({ collection: new Persons(), el: $("#persons") });, but instead he chooses to skip that and test on view.$. It will hold the HTML of the view in memory. This lets you write tests for the view without having to setup DOM fixtures and actually render contents to the DOM. Result: tests that are less complex to write and faster to run.

I know, the title of the article was "integration testing" with backbone

Or even better: use both unit/integration tests of the code itself and browser-based tests like selenium/capybara.