Rails view/controller testing with rspec best practices

Question

For controller tests, Rails recommends to check for things like HTTP response, authentication, assigns, session and flash messages. However in the app I'm working with right now I see a lot of Rspec tests with response.body.should have_tag(), which, as far as I can tell, would ideally be suited for view tests.

What I'm wondering about is:

Is there any considerable performance/other-kind-of penalty related to such unideal way of testing?

Answer 1

If you are rendering views in your controller this will make your controller tests take more time. It all depends on whether you think it's worthwhile to test for the presence of view elements (which tends to make your tests more brittle). If you do, then doing it in the controller specs makes it easier since you don't have to write out a separate view spec file.

If you want to test a lot of things on your views, then you'll probably want to write the separate view specs. Separating out view specs will probably make the overall time for your test suite to run increase. However, for debugging purposes, it'll be clear whether something is wrong in a view vs. a controller with things separated out.

I suspect most Rails programmers don't write view specs. Instead they are probably relying on their integration tests (Capybara +/- Cucumber) to test their views. However integration tests take more time than unit tests. The RSpec book gives the following argument for writing separate view specs:

View specs provide us with an opportunity to discover APIs that we need from the controllers and models. This is not that valuable when the APIs are following the most standard conventions. The value increases, however, as we stray from them....

The only way to really get a feel for the benefits of them [view tests] is to learn to write them well. And only once you really understand how they fit in the flow are you going to be able to make well-grounded decisions about if and when to use them.