I've only recently become much better about testing and TDD in general and it's only since I actually started trying to do it. It's much more rewarding than I e

I've only recently become much better about testing and TDD in general and it's only since I actually started trying to do it. It's much more rewarding than I ever gave it credit for and it gives me an opportunity to keep my code from violating a lot of bad design practices. Addressing a few of your points: b) Absolutely, it's not easy to keep testing when incorporating 3rd party data sources and APIs. I've found that Dependency Injection is a hugely useful tool for attacking this kind of situation. Take this small snippet: def save_image(s3_library=AWS::S3::S3Object) s3_library.store(...) end I just was working on this today. Typically you would put your AWS call in the method - this separates it into an injectable dependency that you can mock and set expectations on in your tests. In fact, once you start doing this, you quickly realize why the Law of Demeter is such a good idea! Stick to testing only the behavior of the current class and relentlessly stub and set expectations for collaborators - each collaborator already has its own set of unit tests (presumably) so testing the results of collaborators does not add value and makes tests harder to maintain. c) It sure does feel like you're writing the app twice and I've fought with myself over this very issue. I have compromised with not forcing everything to have a test and instead to test things that aren't default crud. Alternatively, look at it as an investment in maintainability and refactorability. I recently switched away from using Cucumber to using Rspec's built-in integration testing methods and I feel a lot happier writing integration tests. I encourage you to evaluate why you think Cucumber is a good idea and seriously consider discarding the layer of indirection that gherkin introduces.