"Because you want to ensure that you always pass the majority of tests, you tend to think about this when you change and extend the program. You therefore are m

"Because you want to ensure that you always pass the majority of tests, you tend to think about this when you change and extend the program. You therefore are more reluctant to make large-scale changes that will lead to the failure of lots of tests. Psychologically, you become conservative to avoid breaking lots of tests." In what way would it be different when doing "test-after", instead of "test-first"? There's an inherent difficulty of writing robust, isolated and fast tests ; test-first development is not the cause here. Writing good tests is hard, and it's even harder when your code wasn't designed with testability in mind. To TDD or not to TDD, that's not the question. You should be able, as a test writer, to see and isolate things that prevents testability: I/O, timers, threads, rand(), minimal computation time, clumsy interfaces, etc. TDD just puts these things in front of your eyes, early.