There are advantages to TDD. It forces you to use your code as you write it, which is a very good way to ensure you have a reasonable API. For example, if you h

There are advantages to TDD. It forces you to use your code as you write it, which is a very good way to ensure you have a reasonable API. For example, if you hate writing your tests, then there may be something wrong with your code. It also ensures that you have /some/ tests, and bad tests are better than no tests. But TDD is really about reaching a good design, not about creating useful tests along the way. One of the reasons is exactly what you state. The unit tests that are created in the course of TDD are extremely tied to the particulars of your implementation, and end up being a maintenance pain point in a large application. It is important for your tests to survive a refactor without needing to be changed. So, it is not uncommon for tests created in the course of TDD to be thrown away after you write some good integration tests / feature specs / whatever you'd like to call them for your code. TDD is not, however, the only way to get to good design. You can also use behavior driven development (BDD) -- which is similar. Or you can just get in front of a whiteboard. Whatever works for you. At the end of the day what matters is getting to good design and good tests in a way that's efficient and enjoyable for you.