-1

I am using LocomotiveJS to build an MVC application. I have been thinking about the type of tests I should write and am confused.

Here are the different components in the application - Models, Views, Controllers, Router and the ORM.

If I had to unit test every component, here is how I think I should approach it.

  1. Write tests to ensure the API provided by ORM act the way I expect it to.
  2. Unit test my Model stubbing the ORM. I provide it the stub so I do not have to rely on actual database operations in my unit test.
  3. A Controller accesses Views and Models. A Controller's job is to get/modify the model and to respond to the client (render/redirect).
    • The controller's response can be tested by providing them test inputs and checking if the right response is generated (stub out render/redirect and make sure the right calls are made).
    • Model manipulation by the controller can be tested by stubbing out the model and ensuring the right calls are made. This feels wrong, since I am testing the implementation...
  4. Views are just templates; the controller binds the templates with values. I could create a fake view model and bind it to the view and see if the right output is generated.
  5. Routes just take the request and map it to the right Controller and Action. I can ensure the right routes are supported by the app by stubbing out parts of the Router and making sure a request to the router is mapped to the expected Controller/Action.

Say I change a model API now, I have to change the model test, I have to change the model stubs used by the controller test and I have to update the assertions in controller test.

This seems like overkill.

Does this rather make sense?

Do 1 and 2 as above.

3. Integration test the rest (Controller/View/Router). Here I think I should just start up my app in a test environment and use supertest to ensure the requests generate the right responses - visiting an url, I get the right content, right redirects etc.

I think it makes sense to unit test the model because it represents an interaction with a different system (data persistence). We want to make sure the bridge functions properly. Router/Controller/View interact within our own system and in very specific ways. So it seems okay to integration test that. What are your thoughts?

Aishwar
  • 9,284
  • 10
  • 59
  • 80
  • You forgot having to change the controller code, which having to change the controller test was supposed to remind you of. So I'd call it "not enough kill". – darch Mar 13 '13 at 00:55
  • @darch: I might be mistaken, but I think that's sarcasm :) ... this is a genuine question. So if this is not overkill, is this what people do when testing MVC apps? Frameworks like Rails seem to favour functional testing which looks a lot like integration testing.. – Aishwar Mar 13 '13 at 05:54

1 Answers1

0

If you rely on integration tests, you will lose the benefits of unit tests. Your tests will run more slowly than they need to and will therefore be run less often. Your tests will not tell you where you broke something. Your tests will not exercise as much of the functionality of the application. Your tests will be only half as effective as documentation. You will not be able to TDD.

Overall, any time someone chooses to forgo unit tests in the interest of speed, they go more slowly.

darch
  • 4,200
  • 1
  • 20
  • 23