Question

I have this method:

public bool CanExecute() 

And after 70 commits, I added an extra parameter

public bool CanExecute(IStation target) 

Now the problem is I have 7 unit tests covering this CanExecute methods testing various nulls/property combinations.

Adding this simple parameter required a fix of those 7 unit tests. The fix is simple but…

Is there a best practice and/or pattern to avoid this kind of hand-refactor required to update unit tests?

Suppose I know an extra parameter might be added in the near future, how’d I code the unit test to account for that? Is it just overkill or is there an idiom/pattern/something to follow?

EDIT: I could not simply add an overload because the IStation dependency is not optional. I was fixing a bug where an IStation instance was expected but none was available so it must be supplied via CanExecute… you see.

Refactoring tools seem to be the way to go. Thanks!

Answer 1

If you know that the method is likely to change yet again, I think the sensible thing to do is overload the method and add unit tests for the overloaded members, instead of changing old unit tests. If the stars align for you, you might even find that the overloaded methods call the original no-arg method, so you only have to write tests for the new parameters, and not repeat the original seven tests.