-
Notifications
You must be signed in to change notification settings - Fork 57
Add render_views
to all controller specs
#648
Comments
Good idea! We can revisit the idea of view specs, if you think they'd be worth the time to write. Since our current design is pretty well ironed out, we'd mostly be testing after the fact. |
I'm not sure - I think view specs are more pain than gain, but I'm honestly not clear on what they should be testing. Maybe we should consider it if we can't figure out how to make integration tests ( #416 ) work? |
Sure. When I did the Rails Tutorial we wrote tests to ensure that various UI elements were present on different views, but I guess those were more in the context of integration tests. There's probably more value in writing them before the design of the views is finalized, although I guess it's also hard to be specific about what should be where without actually doing the layout beforehand. I'm not sure they're worth the time at this stage, but we can keep them in mind. |
This is definitely worth doing, especially in the absence of integration tests. Moving to v4.1. |
Now that integration tests are working and we've got a bunch of them set up (see #1219), I don't think we need the overhead of testing views in the controller specs. We should just work on expanding our integration test suite. |
Currently, views do not get evaluated by our tests at all. Invoking
render_views
means that whenever we invoke a controller action, RSpec attempts to render the view template as well, rather than mocking it. At the cost of some slow-down, this means that template code gets executed and thus tested for syntax errors, which - in absence of view specs, which we don't plan to write - is a bare minimum we can do.The text was updated successfully, but these errors were encountered: