4 ms·

Why not just use capybara and the selenium or webkit drivers?

kjbekkelund 14y ago
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.
- hugs 14y ago
  You can write your browser automation tests in JavaScript. See WebDriverJS, Jelly, or PhantomJS. * http://code.google.com/p/selenium/wiki/WebDriverJs http://code.google.com/p/selenium/wiki/WebDriverJs * http://jelly.io http://jelly.io * http://phantomjs.org/ http://phantomjs.org/
netzpirat 14y ago
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.
- kjbekkelund 14y ago
  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 ...).
- mobmad 14y ago
  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.
- scottschulthess 14y ago
  I know, the title of the article was "integration testing" with backbone
brown9-2 14y ago
Or even better: use both unit/integration tests of the code itself and browser-based tests like selenium/capybara.

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.

hugs 14y ago
You can write your browser automation tests in JavaScript. See WebDriverJS, Jelly, or PhantomJS. * http://code.google.com/p/selenium/wiki/WebDriverJs http://code.google.com/p/selenium/wiki/WebDriverJs * http://jelly.io http://jelly.io * http://phantomjs.org/ http://phantomjs.org/

netzpirat 14y ago

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.

kjbekkelund 14y ago
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 ...).
mobmad 14y ago
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.
scottschulthess 14y ago
I know, the title of the article was "integration testing" with backbone

brown9-2 14y ago

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