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.
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.
This is the point I was getting at. Not that this style is bad or good (I think it is good) but that these aren't tests that span modules.
It is common practice (and a good one) to mock the server from the JS perspective as to isolate it, but I dont think this in itself gives it integration test status.
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.
Hey, not saying ths isn't awesome :-) in fact, what you've done here must give you a lot of confidence in your codebase.
However, bugs can creep in when two modules interact. From another comment it sounds like you are seeing how modules interact with each other, I guess the reason I point out the terminology issues are because folks on here are curious about testing and there's a lot of confusion around ths area already.
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.