They're all valid points to an extent. A single developer can follow TDD even if their team does not, but a single developer a team does not make. To effectively adopt TDD, your team should adopt it together, not just an individual here, and an individual there. We want people to be creative, but we don't necessarily want developers following their own ideals in development if it's contrary to the way the team, or department works.
TDD requires a certain amount of knowledge and fixed scope ahead of time. On some projects this is achievable, on a lot of projects where time and budget is a constraint, it's just not practical. It has strengths and weaknesses, such as providing a blueprint for your application and known logic ahead of time. That in itself is also a weakness, because it has a dependency on requirements not changing frequently.
Indeed, you could pick any arbitrary work and write a failing test for it, so that you know what the design is going to be ahead of time. But if for some reason, you're no longer able to fulfill your TDD contract, you have a failing test - that may even end up in the primary code base.
As for the example of developing an application based on docs, and not being able to guarantee the completeness and correctness until production, that's just insane.
I'm not against TDD, I just don't agree that you can, or should, use TDD in every scenario listed above, because a lot of people don't know how to use it.
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.
They're all valid points to an extent. A single developer can follow TDD even if their team does not, but a single developer a team does not make. To effectively adopt TDD, your team should adopt it together, not just an individual here, and an individual there. We want people to be creative, but we don't necessarily want developers following their own ideals in development if it's contrary to the way the team, or department works.
TDD requires a certain amount of knowledge and fixed scope ahead of time. On some projects this is achievable, on a lot of projects where time and budget is a constraint, it's just not practical. It has strengths and weaknesses, such as providing a blueprint for your application and known logic ahead of time. That in itself is also a weakness, because it has a dependency on requirements not changing frequently.
Indeed, you could pick any arbitrary work and write a failing test for it, so that you know what the design is going to be ahead of time. But if for some reason, you're no longer able to fulfill your TDD contract, you have a failing test - that may even end up in the primary code base.
As for the example of developing an application based on docs, and not being able to guarantee the completeness and correctness until production, that's just insane.
I'm not against TDD, I just don't agree that you can, or should, use TDD in every scenario listed above, because a lot of people don't know how to use it.