When it comes to system tests in Rails, I fully agree with David's vision: their benefit/cost is tiny just because their cost is huge. They are a pain to write because of the poor feedback loop and a pain to maintain because of their brittleness. They make deployments slower. And they don't save you from having to test things manually.

Using vanilla Turbo as much as possible helps to reduce their need but I'd argue that even for Javascript-heavy screens, they are not worth it in general. I've come to believe that writing these tests systematically ignores the reality of the tooling we have for them. Yes, if you ignore their costs, their value is terrific. But when you ponder the hours you pour into them, then you wonder what could happen if you stopped writing them. This is my experience: your confidence in the test suite remains the same, but your developer happiness – and overall productivity – increase.

I don't have years of evidence to say how this approach will turn out, but I am optimistic we won't release more bugs. In practice, at development time, you manually test your screens comprehensively, and then you write some system tests that exercise a subset of those interactions. They can catch regressions, for sure, but it’s human testing that will ultimately ensure things work as intended. You can't skip that step, so they are a luxury redundancy. 

Our new apps take the following approach: very few smoke system tests to catch major regressions, fast integration/model/unit tests, and human QA for major changes or new features – which we have always done. We are reviewing the existing apps to align them with this vision.

This approach also enables moving CI to your local box, but that's the subject of another post.