This is why you should try to write hermetic tests. Unit tests should only test one piece of functionality.
Tests are supposed to also act as documentation of functionality. If the functionality changes they should break too, that way you know they need to change.
Your tests ideally should be considered immutable, if functionality changes then you no lo longer need that test and a new one created.
Now if you are doing this maybe you should not because that would be a change to the api contract and should get appropriate depreciation and tests should continue to pass.
That said being in QA I have not dived into writing tests at the unit level. I do isolated integration testing. I don't have a lot of say on the architecture and since I think curtain testability architectures can be harmful to readability don't think that is always the correct level to test at.
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.
This is why you should try to write hermetic tests. Unit tests should only test one piece of functionality.
Tests are supposed to also act as documentation of functionality. If the functionality changes they should break too, that way you know they need to change.
Your tests ideally should be considered immutable, if functionality changes then you no lo longer need that test and a new one created.
Now if you are doing this maybe you should not because that would be a change to the api contract and should get appropriate depreciation and tests should continue to pass.
That said being in QA I have not dived into writing tests at the unit level. I do isolated integration testing. I don't have a lot of say on the architecture and since I think curtain testability architectures can be harmful to readability don't think that is always the correct level to test at.