This is somewhat a reaction to https://www.youtube.com/watch?v=fPlBLlE8vOI .
Overall, TDD is good. I always work on mistakes through TDD – first I try to write a test that won’t pass, then fix it so that it passes.
Working on a typical functional task for a backend: add a new http endpoint or complicate the behavior of the current one. Next, we consider this scenario.
In most cases, the application structure is already there, and the functionality itself is clear how to organize it. So you can write the code first, and then cover it with tests. At this stage, it is important not to run the code, but to initially test it through tests. Then there is no loss of time for manual testing.
The size of such a block of code feels like it, but I try to do MR/PR once a day, when it doesn’t work, then once every 2 days.
At the same time, yes, it is important, as in the case of TDD, to write only the necessary code.
What is the advantage of this approach? The fact is that refactoring is noticeably faster. I don’t see the point in the fact that the written code needs to be tested first and then refactored (when it all happens within one, maximum two working days). I wrote the code, immediately refactored it, and covered it with tests.
It happens that after communicating with the developers who will use the code, you also need to change the system a little: the structure of the response, add some kind of flag. If you do this with written tests, then both refactoring and changes lead to changes in the tests, so it takes longer (and morally harder).
Isn’t refactoring supposed to change the tests? If we try to fully cover the code with tests, then it leads.
As a result, TDD is good, especially in difficult situations or with support, but to reduce time, you can do tests immediately after coding.