Personally, I've found that TDD works well at the Integration/Acceptance/Verification/E2E test level but not so much at the Unit Test level.
The business logic of your application should be well nailed down. The interactions between the "clients" of your app - be that a web browser, a REST API, or whatever it is - should be well designed and documented. And the way that the backend is actually implemented shouldn't change that. This is ideal for a TDD approach.
The individual classes/methods/files/etc in your app are going to be in a high state of flux. They might totally change next week. And as long as they individually work, and deliver the same business logic at the end of it, it doesn't matter. This is less ideal for a TDD approach, but still wants to be tested to ensure that they don't break down the line.
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.
Personally, I've found that TDD works well at the Integration/Acceptance/Verification/E2E test level but not so much at the Unit Test level.
The business logic of your application should be well nailed down. The interactions between the "clients" of your app - be that a web browser, a REST API, or whatever it is - should be well designed and documented. And the way that the backend is actually implemented shouldn't change that. This is ideal for a TDD approach.
The individual classes/methods/files/etc in your app are going to be in a high state of flux. They might totally change next week. And as long as they individually work, and deliver the same business logic at the end of it, it doesn't matter. This is less ideal for a TDD approach, but still wants to be tested to ensure that they don't break down the line.