Totally agreed. No need to test the framework itself. We should trust that the ember and the classes it generates behave as expected. The reason we can trust it is because those classes have awesome unit tests. I trust that ember will wrap my objects in a controller when I specify an itemController because the specs say so.
Custom code we write deserves the same. Like when we replace generated controllers, routes and views with application-specific behavior. We should be able to use TDD, write failing integration test, drop down to into unit tests, then red-green-refactor until the integration tests pass.
For example, let’s say I am coding the blog app from ember guides homepage (https://github.com/tildeio/bloggr-client) and I want to add the edit post feature
Start with Integration test:
I would write a test like: “Given there is an existing post, when I visit the post, click edit, modify it’s contents and click done then my changes should be saved.”
The test is going to drive app from end-user perspective (clicking, etc) and it would fail cause there is no edit button yet.
Now I start writing some unit tests
- PostController#edit() changes isEditing to true
- PostController#doneEditing() changes isEditing to false
- PostController#doneEditing() sends commit() to store
Might also write one for PostView. Could see skipping this as it really just tests the template. Curious if/how others would test this. Anyway, tests verify that:
- PostView shows edit button when isEditing=false
- PostView shows editor when isEditing=true
Awesome. Mine too actually, at least for the most part.
What would help me (and i hope others) is having patterns and best practices to build from. It’s not rocket science but there are lots of decisions to make. Like for example if/when to test bindings and computed properties. As it stands I feel like I am trying to re-invent the wheel.
I guess what i am wondering is how/when do other people write unit tests for their routes/controllers/views/models? I want to find 3-4 solid examples of each.