If you view the views in your controller, this will result in your control tests taking longer. It all depends on whether you consider it appropriate to check for elements of the review (which, as a rule, makes your tests more fragile). If you do this, it will be easier to do this in the specifications of the controller, since you do not need to write out a separate view specification file.
If you want to test a lot of things in your views, you probably want to write separate specs of the form. Separating view specs, it is likely that the total time that your test suite will run will increase. However, for debugging purposes, it will be clear that something is wrong in the view against the controller with things disabled.
I suspect most Rails programmers don't write view specifications. Instead, they probably rely on their integration tests (Capybara +/- Cucumber) to test their views. However, integration tests take longer than unit tests. The RSpec book provides the following argument for writing individual view specifications:
Looking at the specifications gives us the opportunity to open the APIs that we need from controllers and models. This is not so valuable when the APIs comply with the most standard conventions. However, the value increases when we deviate from them ....
The only way to get an idea of ββthe benefits of them [viewing tests] is to learn to write them well. And only when you really understand how they fit into the flow, you can make informed decisions about when and when to use them.
source share