Hacker News Reader

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.