6 ms·

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'

by bnorton 14y ago

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.

chris_wot 14y ago
You are conflating Acceptance testing with Integration testing. Integration testing allows the interaction of modules or components to be tested. Acceptance testing is larger than this - it tests to ensure that the design has been met. But I tend to agree - these do look like unit tests, using a mocking framework. Unless I've missed something, I can't see different modules interacting. This doesn't mean that ths bad (actually, it's really interesting to see what they've done here!), and actually it should definitely help them have a higher degree of confidence in their code.
- kjbekkelund 14y ago
  I don't know if you have used Backbone.js, but these tests ensure that models, collection, views, templates, events and our business logic work properly together. It was difficult to show all that in a few small examples.
  - chris_wot 14y ago
    I know next to nothing about backbone.js :-) I guess I could only go by the examples that were shown. If you are testing how your different software components interact, then you are obviously doing integration testing... Perhaps a better example would have been to take two modules and show how you test that they work together.
kjbekkelund 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      http://blog.involver.com/2012/01/26/testing-backbone-js-best-practices-2/ http://blog.involver.com/2012/01/26/testing-backbone-js-best...
    - 14y ago

by bnorton 14y ago

chris_wot 14y ago

You are conflating Acceptance testing with Integration testing. Integration testing allows the interaction of modules or components to be tested. Acceptance testing is larger than this - it tests to ensure that the design has been met. But I tend to agree - these do look like unit tests, using a mocking framework. Unless I've missed something, I can't see different modules interacting. This doesn't mean that ths bad (actually, it's really interesting to see what they've done here!), and actually it should definitely help them have a higher degree of confidence in their code.

kjbekkelund 14y ago
I don't know if you have used Backbone.js, but these tests ensure that models, collection, views, templates, events and our business logic work properly together. It was difficult to show all that in a few small examples.
- chris_wot 14y ago
  I know next to nothing about backbone.js :-) I guess I could only go by the examples that were shown. If you are testing how your different software components interact, then you are obviously doing integration testing... Perhaps a better example would have been to take two modules and show how you test that they work together.

kjbekkelund 14y ago

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 14y ago
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 14y ago
  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 14y ago
    http://blog.involver.com/2012/01/26/testing-backbone-js-best-practices-2/ http://blog.involver.com/2012/01/26/testing-backbone-js-best...
  - 14y ago