

Integration testing Backbone.js - chillax
http://open.bekk.no/integration-testing-backbone-js/

======
bnorton
It still seems more like unit tests..

For example this line states that if you are given 20 records that 20 make it
into the view.

expect(view.$('.persons li').length).toEqual(20);

This mocks out the server to give 20 results back and simply tests that the
template iterates over the returned collection (given that the 'reset' binding
for view.render is in place). You are specifically not in an 'integration'.

As for the argument for not using capybara for speed reasons - it seems that
the speed difference is acceptable given the confidence and power it gives
you.

This is not the same as an integration (acceptance) test. Whence you mock the
server you can no longer be confident that a breaking change was not
introduced across the stack.

The purpose of integration tests is that you are the user, and express your
functionality in the same manner that the user would.

This is not that. It is therefore not an integration test.

~~~
kjbekkelund
But does it matter if they are somewhat like unit tests or somewhat like
integration tests? Isn't this just nitpicking on the definition of an
integration tests? According to Wikipedia: "Integration testing [...] is the
phase in software testing in which individual software modules are combined
and tested as a group." That's what we are doing here. We are testing that the
entire _client-side_ application works as expected.

And yes, I totally agree with you regarding the confidence we can have when we
mock out our server-side application. But in the context we were working it
would be a world of pain to have proper acceptance tests going through the
entire stack. They would also take much, much longer time than about a second
(we are not in a regular database type application using Rails and all that,
this is an enterprise project with many, many years of legacy code in it and
an ESB and whatnot).

The purpose of these tests for us is first of all to be able to deliver
functionality fast and with high confidence, which they, beyond a doubt, has
helped us with.

~~~
chris_wot
Don't know about this being nitpicking or not. Sounds like a terminology
problem. What you are essentially doing is mocking out the XHR requests and
performing unit tests on the client side. An excellent thing to do, but you
aren't really testing that individual modules are able to interact together
correctly, which is the purpose of integration testing.

~~~
kjbekkelund
Okey, so let's just say that I'm testing in a way I haven't seen mentioned by
anyone with regards to Backbone.js. The point is the execution, not the
naming.

Btw, if anyone has been talking about / doing similar testing of Backbone.js,
I would love to share some insights and ideas.

~~~
bnorton
[http://blog.involver.com/2012/01/26/testing-backbone-js-
best...](http://blog.involver.com/2012/01/26/testing-backbone-js-best-
practices-2/)

------
tbranyen
While you may have confidence your code is working as expected, you are
missing out on the importance of unit tests. The point of unit tests is to
ensure _your_ code works as expected. In your write up all I see are tests for
Backbone.js, which btw, already has unit tests.

When you do something like:

var collection = new SomeCollection(); collection.fetch();

assert(collection.length === some_number);

How are you testing _your_ code here? You're going through the library
abstraction which is Backbone. The tests are making sure Backbone can fetch
and populate a collection.

I'm not sure I see the value. Instead you should be testing that your code is
set up properly and leaving the trust to Backbone which you're using because
you have some level of trust in it =)

~~~
mobmad
I think you need to read the post again.

In the first example, he:

    
    
      - initializes a view
      - asks the collection to fetch itself
      - asserts that the VIEW now has 20 person elements, not the collection.
    

What this first test does is asserting that the "PersonsView" and its event
binding and logic is setup correctly.

The same applies for the second example where PersonsView is the object under
test. In this example he asserts that an ".errors" element exists in the view
if the ajax request fails. I.e. that view logic and event binding for error
handling is setup correctly.

Both cases test custom code in PersonsView. The tests would probably fail if
PersonsView->initialize or PersonsView->render didn't behave correctly. As far
I can tell, no code test Backbone in itself.

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

~~~
netzpirat
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
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 ...).

