| > And refactoring your code should not result in changes to the unit tests as the purpose of the unit test is to tell you if your refactoring broke something. If you have to change your unit tests when you refactor, you're doing something wrong I disagree a bit here. Without getting pendantic about units and refactors, in practice, it is common to want to modify methods that have unit tests for them. Maybe you want to break out the method into two, or break the class into two classes, or you want to improve the method's interface, change the types it takes, its parameters, the structure it returns, etc. All these changes will most likely break your unit tests. If they didn't break the unit tests for the method, I'd actually be curious what it was even testing. Above this, people often in practice also unit tests private methods, so you've often got to deal with those type of unit tests as well even if you're only touching the inside of a class and leaving the public methods intact. And beyond refactoring, sometimes you are simply adding a new feature or fixing a bug, and this will result in you maybe choosing to modify the behavior of some existing class and its methods. These changes will also break your unit tests. What all the use cases I just listed have in common is that all of them have good reasons to break the unit tests, and will result in people simply going and changing the tests to reflect the new changes. |