5 ms·

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

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 =)

kjbekkelund 14y ago
If you look at the examples I'm not testing that collection.length is some length, I'm checking that the actual output of my application is correct. For example, in the last example I'm checking that my application handles errors properly. In our app we have nearly no business logic at all, and we have tested our REST endpoints thoroughly, so we felt we didn't get nearly any value out of unit tests (we wrote about a hundred of them before we changed our primary focus). So, what these tests actually test is that all events are triggered properly, that what I expect to see is actually what's in the view, and so on. Yeah, this also means that _some_ tests are close to Backbone.js functionality only, but most are far from it when the application grows in complexity. We have a lot of custom events, both the regular Backbone model and collection events and also a lot of global events. So no, I actually don't agree that we are missing out on the importance of unit tests. We have fully test-driven a large application over 6 months and found a way that works great for us, and that allows us to be flexible and deliver functionality fast, at the same time as we have confidence in not breaking functionality.
mobmad 14y ago
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.

kjbekkelund 14y ago

If you look at the examples I'm not testing that collection.length is some length, I'm checking that the actual output of my application is correct. For example, in the last example I'm checking that my application handles errors properly. In our app we have nearly no business logic at all, and we have tested our REST endpoints thoroughly, so we felt we didn't get nearly any value out of unit tests (we wrote about a hundred of them before we changed our primary focus). So, what these tests actually test is that all events are triggered properly, that what I expect to see is actually what's in the view, and so on. Yeah, this also means that _some_ tests are close to Backbone.js functionality only, but most are far from it when the application grows in complexity. We have a lot of custom events, both the regular Backbone model and collection events and also a lot of global events. So no, I actually don't agree that we are missing out on the importance of unit tests. We have fully test-driven a large application over 6 months and found a way that works great for us, and that allows us to be flexible and deliver functionality fast, at the same time as we have confidence in not breaking functionality.

mobmad 14y ago

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.