In which case we should write views Controller tests

Testing Test-Driven Rails Tutorial
1

I watched all the episodes on the Test Driven Rails Workshop, and Josh did a good job explaining the different pieces. But I am wondering, why he did not write tests for controllers and views? while building the Todo application outside-in. This approach is quite different from what I’ve read in “the Rspec Book”, where David wrotes tests for every piece, from the views down to models.
So if this is the right way to do testing, when we have to write Views and Controllers tests? And what are the pros and cons of not writing the views and controllers tests?

2

Thoughtbot’s testing strategy is to only add controller and view specs when the objects under test are suitably complicated that they cant be covered by a higher level acceptance test such as a feature spec. This style means testing “just enough”, where all tests pull their weight instead of being a maintenance burden.

2 Likes
3

I think writing tests that covers as much as possible is the right way to go. You’ll have a hard time covering edge cases in integration tests. I also prefer to look at the controller as a unit (think unit tests) that delegates work/logic to different objects/models and deals with rendering the view, returning 404s etc.

Views are also important to test in isolation when you really want something specific (especially something that the user can’t see, and you feel like it doesn’t belong in an integration test). For example you need to test that a meta tag is present (maybe for SEO purposes).

Hope that helps,
Cezar

4

I find that its certainly possible to test views and controller well through integration tests alone. However those tests are slow the feedback you get from the errors are often not very helpful.

I try to write integration tests when I start implementing a feature and when I feel like I need more fine grained feedback from my tests I’ll drop into either controller or view tests.

I also usually only test one happy and one sad path in integration tests and leave the edge cases to the unit tests, because they are faster and usually more direct.

1 Like