I totally get what you're saying and I also faced the same problem when starting out with TDD. However, it took me a few years to understand that good tests are tied to the behavior. As a result, if something has to refactored because of a PR comment it doesn't break a test - because refactoring is all about changing implementation details, it doesn't change the behavior you expect from a class/function.
I think you should have emphasized more on this in your post, I personally believe it is one of the most important aspect of TDD and how it becomes an agile practice. Writing test after will be tied to your implementation 100% of the time, just try it, even if you know TDD you will have a hard time writing a test not tied to your implementation after coding it, you are biased, and will be a really hard mental exercise.
Writing the test first challenge the design and the user needs, if you can't write the test because there are too many aspect you don't understand, review the design don't start an implementation that will probably fail to answer the need. Never implement without a test really means never implement when your design is not though out.
As you mentioned since test should not be tied to your implementation but to the users needs you can change your implementation any times you want and your test will even help you do it faster without breaking anything for your users.
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 totally get what you're saying and I also faced the same problem when starting out with TDD. However, it took me a few years to understand that good tests are tied to the behavior. As a result, if something has to refactored because of a PR comment it doesn't break a test - because refactoring is all about changing implementation details, it doesn't change the behavior you expect from a class/function.
I think you should have emphasized more on this in your post, I personally believe it is one of the most important aspect of TDD and how it becomes an agile practice. Writing test after will be tied to your implementation 100% of the time, just try it, even if you know TDD you will have a hard time writing a test not tied to your implementation after coding it, you are biased, and will be a really hard mental exercise.
Writing the test first challenge the design and the user needs, if you can't write the test because there are too many aspect you don't understand, review the design don't start an implementation that will probably fail to answer the need. Never implement without a test really means never implement when your design is not though out.
As you mentioned since test should not be tied to your implementation but to the users needs you can change your implementation any times you want and your test will even help you do it faster without breaking anything for your users.