3 ms·
Public interfaces should change only under extreme circumstances, so needing to refactor legacy tests should be a rare event. Those legacy tests will help ensur
by randomdata 4y ago
Public interfaces should change only under extreme circumstances, so needing to refactor legacy tests should be a rare event. Those legacy tests will help ensure that your public interface hasn't changed as it is extended to support changing requirements. You should not be testing private functions, leaving you free to refactor endlessly behind the public interface. What goes on behind the public interface is to be considered a black box. The code will ultimately be tested by virtue of the public interface being tested.
- __ryan__ 4y agoOh, I didn't consider this. Problem solved then.
- kcb 4y agoAssuming any piece of code won't or shouldn't be changed feels wrong. If you're a library developer you have to put processes in place to account for possible change. If not those public interfaces are just as refactorable as any other code imo. Nothing would be worse than not being able to implement a solution in the best manner because someone decided on an interface a year ago and enshrined it in unit tests.
- randomdata 4y agoMuch, much worse is users having to deal with things randomly breaking after an update because someone decided they could make it better. That's not to say you can't seek improvement. The public interface can be expanded without impacting existing uses. If, for example, an existing function doesn't reflect your current view of the world add a new one rather than try to jerry-rig the old one. If the new solutions are radically different such that you are essentially rewriting your code from scratch, a clean break is probably the better route to go. If you are confident that existing users are no longer touching your legacy code, remove it rather than refactor it.