Very cool! In fact, you are almost doing TDD, but missing the final step: Refactor Mercilessly http://c2.com/xp/RefactorMercilessly.html TDD directly hel

Very cool! In fact, you are almost doing TDD, but missing the final step: Refactor Mercilessly http://c2.com/xp/RefactorMercilessly.html TDD directly helps you with interface design, that is how the pieces fit together. It helps you indirectly with the design of your implementations, because it enables this merciless refactoring. "you write tests to model the problem then you write code to pass the tests" Exactly! And once you have the code that passes the tests, and have written enough of it to have somewhat decent coverage for the problem-space, you can then refactor the implementation. That is where you can go wild with your ideas, because you are only making changes to code that is already working and protected by a test-suite. https://stackoverflow.com/questions/78806/refactor-mercilessly-or-build-one-to-throw-away#78844 For me this splitting of the very difficult programming tasks into 3 distinct and much simpler steps is the beauty of TDD: 1. Figure out the problem (write a spec as executable tests) 2. Make it work (just write trivial code to get the tests green) 3. Refactor (go wild with your design ideas, make sure tests stay green)