It Depends

I use mocks and fake data a lot these days. Mocking is especially helpful for unit testing. I use Moq framework.

I am not going to talk about the need of unit testing. I think it’s not a topic for discussion anymore. But in order to use unit tests effectively application should be designed for testability. Design for testability is actually not that difficult. Application layers should interact via interfaces rather than concrete classes and should have a mechanism to "inject" a real or mock implementations.

Following this principle gains a lot of benefits and is very easy … when you begin developing a new application. Unfortunately sometimes you have to work with a legacy code that was not designed for testability. What should you do in this case? Throw unit testing away and do manual testing? Well, that’s a solution, but …

Last week I’ve developed a new feature for an existing application and was adding unit tests for it. I’ve quickly realized that because of the call to a legacy method I cannot follow my usual mocking routine: legacy code didn’t have interfaces and, even worse, the class is sealed. For a second I was considering to go without unit tests and hope that in the future everything will be fine. Then I’ve realized that there is a solutions I have refactored my code so that the call to a legacy method can be mocked.

Here is the original method where I have to make a call to a method from a legacy sealed class:

public string Upgrade(Customer customer)
{
    var accounts = legacyClass.CallLegacyMethod(customer);     

    var result = accounts != null ?
        ProcessAccounts(accounts) :
        HandleCustomerWithNoAccounts(customer);     

    return result;
}

After a quick refactoring the same method became unit test friendly:

private Customer customer;
private IEnumerable<Account> accounts;

public IEnumerable<Account> Accounts
{
	get
	{
		if (accounts == null)
			accounts = CallLegacyMethod(customer);
		return accounts;
	}
	set {	accounts = value; }
}

public string Upgrade(Customer customer)
{
	this.customer = customer;

	var result = Accounts != null ?
		ProcessAccounts(accounts) :
		HandleCustomerWithNoAccounts(customer);

	return result;
}

And here is the unit test were I can mock (or fake) the result of the call to that legacy method:

[TestMethod]
public void Upgrade_Mocked()
{
	var fakeAccounts = GenerateFakeAccounts();
	var customer = GenerateFakeCustomer();
	processor.Accounts = fakeAccounts;

	var actual = processor.Upgrade(customer);

	//Assert
}

Unit test unfriendly legacy code is not an excuse for a bad quality of your own code. Just remind yourself that although you cannot control others’ code (and others) you can always control your code (and yourself).