My point is that tests have a tendency to solidify existing code.
If the code is changing before it's even released, this is time wasted.
Write the code, solve the use cases, then write your tests. Before you have something concretely written, things are in flux and writing tests at that point is a waste of time.
That said, sometimes I break this philosophy. Sometimes I write unit tests immediately after I have written a small component.
But to take tdd as an overall approach to development would be hard to justify in my opinion. Maybe exceptions are if you are writing machine control software, or mission critical application. But in such cases you are probably using waterfall.
Sorry but I have to disagree. A large point of TDD is to allow for this. You write a test that describes the functionality that you want, then write the implementation. After you can refactor, change, rewrite the implementation as much as you want and the test it still valid. If you need to change the functionality then this can be done be first updating the tests.
If you work in an agile environment as you suggested you should be creating small, potentially shippable products. So once you have implemented something, it shouldn't be changing too much especially before you release, as it will have been agreed before brought into sprint.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.