One nice advantage of TDD is that you don't risk building a hard to test product. Of course, you have to pay attention to what you are testing and make your test cases meaningful.
One of the problems I've seen ith TDD is that the team decides on a metric of minimum code coverage of x%. Now, in order to achieve x, a large number of basically useless tests end up being written simply for the sake of getting the coverage number up regardless of how poorly thought out those tests are.
That's not an inherent fault of TDD, of course. My point is that the mindset that seems to follow it leads to dumb things like that happening.
One of the problems I've seen ith TDD is that the team decides on a metric of minimum code coverage of x%. Now, in order to achieve x, a large number of basically useless tests end up being written simply for the sake of getting the coverage number up regardless of how poorly thought out those tests are.
That's not an inherent fault of TDD, of course. My point is that the mindset that seems to follow it leads to dumb things like that happening.