First, developers can/should not ran away from unit testing it gives confidence to business that code is tested with proof.
"TDD is writing unit tests to fail and the code.". Every top gun come and say this. This is awesome and whats wrong with it.
But, in real time how you write test cases??
To write test, you need to have concrete interface and method defined, messages defined and complete picture of implementation.Which mean you should have complete design ready no change in this.
If above is not clear, there will be too many turn around to fix code and then fix tests. Over the top, they say, be agile, requirement can change any time.
In agile design and requirement is not 100% clear how can you be sure that actual coding is already done in head of developer before starting development.
Problem with TDD is too much of time wasting and speculating on paper to thing about test cases and loops of code and test.
In my opinion, following is more efficient manner for coding (before sending code to testing team) -
Code rough ⟺ Adhoc Test (manual Test) ⇒ verify business requirement ⟺ Refine the code ⇒ Complete ad-hoc manual unit test ⇒ Write unit tests (rough) ⇒ cover code as much as possible ⇒ Send to Testing team for coding and writing acceptance test.
I would even advocate to just go for rough test and send the code to testing team. In real scenarios testing team can't write their test (Acceptance test) without having code. So while they start writing tests developer can complete the unit tests.