I like TDD if the code is already clean and well-tested, and also if the existing test code is clean. If the domain code is clean but the test code isn't, I'll

I like TDD if the code is already clean and well-tested, and also if the existing test code is clean. If the domain code is clean but the test code isn't, I'll clean up the test code before TDDing the new feature. Shouldn't take long at all. If it is not clean, but well-tested, then I need to clean the code before extending it further. Also the tests will probably be messy, I'll spend time cleaning those up if I have time. But in all likelihood I'll only be able to clean up the code this time around. If it is clean, but not well-tested, then a test-after approach is better. Take your feature-implementing extension, and write tests for both the extension and what it's extending. Then the next time I'll have clean, well-tested code to TDD off of. If it is neither clean nor well-tested, then I wouldn't bother writing tests at all, for this iteration. Instead I'll clean up the code, make my extension, and call it a day. The next time I extend that part of the codebase, I'll use the aforementioned test-after approach. Tests take time to refine and get right. They are an added layer of security, but a much better line of defense is nice clean code that you know what it is doing at a glance. Tests will not save you from bugs, but clean code will make bugs way easier to iron out. The prevailing wisdom seems to be to don't refactor unless you have test code to fall back on and if you don't have that, to write smoke tests. I do not like this approach, I think if you have to deal with unclean, untested legacy code, then you need to do the work to understand it, and the best way to come to an understanding of code is to clean it up. As you clean it up, domain concepts become clearer. Tests are a form of documentation, their intent is to help you understand the codebase. The code itself tells you how it's accomplishing business objectives, tests tell you what those business objectives actually are. Unless you are very unlucky you should have alternative sources for that knowledge. So tests aren't strictly necessary, but they are very nice to have.