> Quality is in design and implementation. Tests are just for increasing engineering efficiency. Yes, precisely. I couldn't have said it better myself. Your or

> Quality is in design and implementation. Tests are just for increasing engineering efficiency. Yes, precisely. I couldn't have said it better myself. Your original comment came across as discounting the importance of tests a lot more than I think you meant it to. But I was also trying to make a couple points about TDD. The first is that watching the tests fail before writing the implementation increases your confidence that there isn't a bug in your test code. This was just to address your #2 bullet point. But this only treats tests as a verification tool, which is orthogonal to good design. Since we agree that tests are for efficiency and we're discussing design, it's not worth dwelling on this point. The second point is that TDD is a useful design tool that can be used in conjunction with upfront design. Upfront design is great for having an overall coherent design, but there are many finer details that are inevitably discovered at implementation time. That's where I think TDD really shines. If you think of building software as sculpting, upfront design is like chiseling out the shape of your statue and TDD is like switching to a more precise tool to etch in small details like hair texture or wrinkles. It's not a perfect metaphor. For example, if you start with a smaller chisel (TDD), you'll end up with the same statue just taking you longer to build. But if you do the same with software development, you'll end up with an arm coming out of the statue's thigh.