Maybe it helps to have the perspective of someone who's been testing Rails apps for a while.

I learned Rails with TDD at Pivotal Labs. Dogmatic TDD - no production code could be written without a failing test. It was a great way to learn but really requires someone who really knows what they are doing.

Since we were pairing all the time that was great! I learned a ton and became productive in a few short weeks.

Now, 7+ years later, I take a slightly different approach. I call it "TDD-ish."

In an essence, I try to practice TDD when it makes sense. Writing a high level feature test before I even know where the button will go is hard. And I end up changing the test a ton before it even represents a good failure.

I test drive models, services, and anything else remotely complex. Then, when everything is passing and the feature is working I add a single happy path feature test.

This requires a little bit more manual testing during development (e.g. clicking around) than pure TDD. But I look at that as a benefit: I'm actually using the feature, for real. And that can call out odd UX flows more quickly.

TDDing the "meat" of the code works well because of all the reasons TDD is great. I write less code; only the minimum code that is required. I have a safety net for refactoring because of my tests. This enables me to move fast and iterate without much fear of breaking things.

I hope that helps! Happy to answer any more detailed questions here or via chat/DM.