TDD doesn't lead to better or worse design, your testing strategy does. TDD changes your approach to testing, but if you choose a poor test strategy then TDD or

TDD doesn't lead to better or worse design, your testing strategy does. TDD changes your approach to testing, but if you choose a poor test strategy then TDD or not, you're going to have a bad time. I hate to say it, but this is yet another misleading article that is doing the programming public a disservice. Here's my testing strategy (YMMV): 1. Feature tests for the "happy path" - make sure the system requirements work as described from the user's perspective with full integration. I usually just write a couple. 2. Integration tests for high-level system components - these are more functional in nature but capture all boundary cases for the components that sit closest to the user. These are my saving grace when refactoring. 3. Unit tests for methods and other low-level components - these primarily serve my "integration tests" by factoring out the functionality of low-level components and allowing me to focus on their integration. Here I'll use mocking if it's convenient, and when refactoring these usually get re-written. Notice that this strategy says nothing about TDD, but I would argue that following the principles of TDD makes this strategy strictly work better.