[darrencauthon]

It all comes down to testing to me. If the dev is writing a test first, questions about where things go are answered pretty quickly. If the tests become painful or awkward, you're probably doing too much in the code.

I think the common Rails response to painful tests is to stop testing. I've heard talk of the "diminishing returns" of testing, or debates of what deserves to be tested. I was once responsible for maintaining many Rails 3 apps that I did not write, and the story was all the same: Either there were no tests, or there were simple tests around simple logic, or there were simple tests covering one or two paths through some really complex logic. Once they felt the pain from their tests, they just stopped writing tests. What else are they going to do... challenge the "Rails Way?"

And this is the community that is supposedly known for their testing. Having used Sinatra or Rails for almost all of my web work for a while, let me tell you: The state of testing in the common Rails app is no different than I've seen anywhere else.

[amalag]

This is a very good point. If you consider from the point of view of what should be tested, then I think what the author proposes could be quite natural. We don't want to duplicate and overlap with Rails tests. For me "what to test" is the hardest question.

[atomical]

The do it because it feels right (or don't do it because it feels wrong) mode of thinking is self-indulgent. When an app becomes larger and more involved so do the tests.