Legacy Code to Testable Code #6: Add Overload

Gil Zilberfeld points to one of the refactoring patterns in unit testing and unit tests that makes legacy code more testable.
Standard

This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing unit tests for legacy code, and how they make our life easier. Other posts include:

The Legacy Code To Testable Code Series

General patternsAccessibilityDealing with dependenciesAdvanced patterns
IntroductionAdd settersExtract methodStatic constructors (initializers)
RenamingMore accessorsExtract classMore static constructors
Add overloadIntroduce parameterInstance constructors
Testable objectConditionals to guard blocks

 

In the last post, I’ve talked about Extract Class refactoring pattern, and that sometimes in order to do that, we might want to change the signature of a method.

Turns out adding an overload helps in other cases as well.

We used a “setter” to expose to the unit test and inject internal state before. Another option is to add a controllable overload to bypass the internal state.

Let’s look at this code:


In this example, we compare an external value to an internal state. As we saw before, the option we could use is add a “setter” accessor, to allow the unit test to inject the internal value from outside. Instead, we can also add an overload:


 

We do the actual comparison on the new overload. The new overload should be accessible to the unit test, depending on language (so it doesn’t have to be completely public). In the original method, we delegate the call to the new implementation.

The new overload is more controllable. We can stop there, but if our logic code does not rely on state anymore, why not use Extract Class refactoring pattern?


The StreetValidator class can now be controlled and tested easily.

Time to wrap up the series. So next time, in the last chapter – using dependency injection framework.

2 thoughts on “Legacy Code to Testable Code #6: Add Overload

  1. Danny,

    I think that static classes, with static methods and no state, have gotten a bad rap. They are easy to test as is.

    Otherwise, it’s just an example, you can create an instance if you like 🙂

    Gil

Leave a Reply

Your email address will not be published. Required fields are marked *