I think it depends on the state of the project whether TDD is the right approach. If you build a prototype PoC from scratch and are alone and have unclear and "agile" specifications, I think TDD slows you down.
But as soon as you have other developers on the team, or work on a project that has matured over time, then TDD helps you catch errors early and avoid massive communication overhead. I see tests often as a communication tool, it's the best way of telling another developer what I intended with this piece of code and that he should not change this behavior lightly.
The problem with TDD and PoCs or prototypes is that is unclear what the program should or shouldn't do in the beginning, you just get a rough idea of the problem you should solve and then explore a solution that might not be right and change rapidly. I do like integration tests on the API level in this state to make sure I don't break something that is already agreed upon, but have the freedom to refactor the whole application underneath without having to adjust too many tests.
I'm not saying you shouldn't write any unit tests when starting a project. When you write code that you know will stay, insure high test coverage. Otherwise, the developers that come after you will have a hard time not breaking stuff and won't feel confident in further developing what you started.
I believe there is just not easy rule on when to write tests or practice TDD it totally depends on the project you are working on.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think it depends on the state of the project whether TDD is the right approach. If you build a prototype PoC from scratch and are alone and have unclear and "agile" specifications, I think TDD slows you down.
But as soon as you have other developers on the team, or work on a project that has matured over time, then TDD helps you catch errors early and avoid massive communication overhead. I see tests often as a communication tool, it's the best way of telling another developer what I intended with this piece of code and that he should not change this behavior lightly.
The problem with TDD and PoCs or prototypes is that is unclear what the program should or shouldn't do in the beginning, you just get a rough idea of the problem you should solve and then explore a solution that might not be right and change rapidly. I do like integration tests on the API level in this state to make sure I don't break something that is already agreed upon, but have the freedom to refactor the whole application underneath without having to adjust too many tests.
I'm not saying you shouldn't write any unit tests when starting a project. When you write code that you know will stay, insure high test coverage. Otherwise, the developers that come after you will have a hard time not breaking stuff and won't feel confident in further developing what you started.
I believe there is just not easy rule on when to write tests or practice TDD it totally depends on the project you are working on.