> One day, I was writing a controller spec to make sure that calling the “index” method with a “get” request would return a 200 status code when I realized how absurd it was.
> What the heck was I doing? Where was the value of this test? There was none. If the index method returns a 404, it’s because I didn’t create the damn template yet. Why would I deploy my application at this stage?
This is so, so wrong I don't even know where to start. If you work on a real-world project, you soon realize how complex and entangled the view layer can become in Rails. Controllers inheriting from non-obvious parents, including modules and helpers that implicitly require instance variables. And to add even more complexity on top of it, before and after filters (or actions since Rails 4) that can be inherited or skipped by children.
Bottom line: considering all the complexities I just enumerated, a controller test that checks the status code of a get request might not be as superfluous as it might sound, it could actually save you a lot of headaches.
None of any of that applies to the point at which he was writing the test, and all of it would be covered by the integration tests he says he writes.
I have seen some truly awful, pointless, tightly-coupled controller tests (testing if an instance variable is assigned, for example) in my career. If there's enough logic in a controller that testing it at a level lower than a general acceptance/integration test is useful, it should almost certainly be in a model or a service object.
Imo you always need to test error cases with web sites and apis specially. It's just stupid that some API returns "200: OK", {"result": {"error": "result not found"}}.
But I guess this is mainly about point of view. I used to be a developer, but now I'm employed full time as tester, so I have very different views on what needs to be tested than developers I know.
> If you work on a real-world project, you soon realize how complex and entangled the view layer can become in Rails. Controllers inheriting from non-obvious parents, including modules and helpers that implicitly require instance variables. And to add even more complexity on top of it, before and after filters (or actions since Rails 4) that can be inherited or skipped by children.
This gives the impression that the real-world Rails programmer doesn't really understand what his programs are doing.
This type of complexity should be covered by architecture (SRP & composition) not tests. The main value of test is revealing the flaws of your code, not making sure it works at all cost.
> What the heck was I doing? Where was the value of this test? There was none. If the index method returns a 404, it’s because I didn’t create the damn template yet. Why would I deploy my application at this stage?
This is so, so wrong I don't even know where to start. If you work on a real-world project, you soon realize how complex and entangled the view layer can become in Rails. Controllers inheriting from non-obvious parents, including modules and helpers that implicitly require instance variables. And to add even more complexity on top of it, before and after filters (or actions since Rails 4) that can be inherited or skipped by children.
Bottom line: considering all the complexities I just enumerated, a controller test that checks the status code of a get request might not be as superfluous as it might sound, it could actually save you a lot of headaches.