TDD is pretty difficult when you don't have a very clear idea of what's the best way to achieve what you want to do – which is most projects most of the time.

It's usually also a hard sell for management, especially if the project is on its first steps and it has to show something functional in order to keep its budget.

Last but not least, the problem domain for unit tests is pretty focused. The parts of the code that are suited for unit testing may not be all that much. I know that TDD is not just unit tests but I mentioned it in the context of this discussion.

[–] renovator_sinner_wisdom_headdress@programming.dev 0 points 1 year ago (1 children)

1st problem - you should be coding such that you can make at least two iterations. It should be perfectly okay to code it once so that you have an idea and then throw it out and do it correctly. If you work in sufficiently small steps, there's barely any time waste plus you save time that you would spend maintaining

2nd problem - Kent Beck's (the guy who "invented" TDD) idea behind TDD was that it should help you be less stressed. If your job is to make a prototype or get something really out the door really fast and you won't lose sleep over it, then there is no need to write tests. TDD is there to enable you.

I am not exactly sure, what you mean with the unit tests, so apologies if I am misunderstanding. I use integration tests in my red-green-refactor loop as well

[–] Psilves1@programming.dev 1 points 1 year ago

Budget+Client expectations don't always give you time for two iterations