Here's my take on testing: I'm the kind of guy who likes to get things working as fast as possible. When I'm excited about an app or feature idea, I can't be

Here's my take on testing: I'm the kind of guy who likes to get things working as fast as possible. When I'm excited about an app or feature idea, I can't be bothered with writing tests along the way, much less before I write my code. I get much more satisfaction out of writing code, running it in the browser, and testing it the old fashioned way. I build apps and features quickly and this usually makes me (or the client I'm building it for) very happy in the process. I do, however, understand the value of testing. Unlike the OP I have seen real world cases where testing has been a godsend. I often feel guilty for not writing tests, even if it's just a toy app I'm developing for my own curiosity. To balance these opposing tendencies of mine, I have taken a ATDD approach to testing, or "Adaptive Test Driven Development". That is, write tests for the most critical components of the site, such as anything dealing with money or sensitive information, and write tests for the parts of the app that get used the most, both by me when I'm developing them, and the users once it's deployed. When I've gone to the browser for the 5th time to test a feature I'm developing, it's a pretty good sign that an automated test would be more efficient than my manual testing, so I set aside the time to write it. If I know there's a part of the app that errors will be completely detrimental to, I will write tests for that, if only for my own psyche. To be completely honest, TDD/BDD and some of the rhetoric surrounding it seems a bit ivory-towerish - a way for the templars of hacking to distinguish themselves from the proletariat developers. If I had been told TDD is the only way I could develop a rails app when I first started doing it I probably would have given up pretty early on. So if TDD is getting in the way of your being productive, it kind of defeats the purpose of it even existing. The important thing is to strike a balance that works for you, and keep an open mind about other developer's habits and tendencies.