Testability != Good Design

It’s a funny thing, code testability. It’s not really defined, or rather, it is defined poorly.

If “testable code” is “code we can test”, that means all code is like that. We can test it through unit tests. If it’s hard we can move to functional tests. And if all fails, we can do manual testing. Even performance testing exercises the code. If there’s code that tests cannot exercise, why did we write it in the first place?

When we talk about code testability, we really mean “hard to test”. That is a whole discussion by itself, because “hard to test” is also subjective. If we follow the theme of unit testing, for example, as an investment to minimize future maintenance costs, then “hard to test” translates to  “Costly to test” or “risky to test”.

So here’s another fun fact: When we have a well-factored code, it requires minimal changes, if any, for it to be tested. There’s no surprise that focusing on SRP makes code testable.

Because well-designed code is testable, we tend to correlate the two. Hard-to-test, legacy code is usually not factored well, and the two properties seem to go together. Moreover, we may infer that testable code leads to good design. It can in many cases, but not always.

Here’s an example. We have a Customer class with a static method that gets the balance of an Account from a Bank:

public bool isOverdrawn(String name, int limit) {
   return (Bank.getAccount(name).getBalance() > limit);
}

If we rule out use of PowerMockito, we need to modify our code to make it ”testable”. We can refactor it to pass the Account as a parameter. Once the Account is passed as an argument (really as an interface), we can mock the IAccount interface and pass it in. We now have testable code.

bool isOverdrawn(int limit, IAccount account) {
   return (account.getBalance() > limit);
}

The method is as readable as before. We exposed the type of account, although I’m not sure we even needed to know about it. We no longer have the name parameter, but instead, we needed the caller to extract the account before the method call, while originally it did not need to bother with the Bank at all.

The design has changed, but maybe not for the better. It definitely complicated the calling code.

Now let’s try another design change for the sake of testability. This time instead of extracting a parameter, we’ll inject it with a dependency injection container (I’ll use Geuce). For that we need to modify the Customer class, and add:

private IAccount account;

@Inject
public void setAccount(IAccount account) {
  this.account = account;
}

bool isOverdrawn(int limit) {
  return (account.getBalance() > limit);
}

For the Customer class, we’ve added an unnecessary public setter, and a field we didn’t need before. If the calling code just used the setter, we’ll be in a similar condition to the last example, but using a DI framework makes the calling code, including wiring and configuration again, more complicated. (By the way, in .net it looks a bit better, but not by much.)

You may argue that sacrificing the simplicity of the calling code in order to make the design of the tested object is ok. But if we’re going to write unit tests for the calling code, you’ll need to use the same tricks, and if you’re not, well, you just made it more complex and susceptible to bugs. We  should unit test it.

Testable code is not inherently designed better

Sometimes the changes are risky and costly. We need to balance the need for unit testing with the risk, and how the tools we use impact the design.

And let’s remember: this code was not “untestable”. We decided to set a constraint to not use PowerMockito, and tried to work around it. We could easily have tested that code as-is.

For years I’ve heard that tools like PowerMockito and Typemock Isolator encourage bad design, because they allow to unit test badly designed code. It sounds bad, but it maybe a better solution than making risky changes so you can just unit test. Sometimes the changes are not even risky, but will create a more complex code, where it should be simple.

Testing and design are broad skills every developer should have.

As long as you’re making a knowledgeable decision, not based on popular slogans, you’ll be fine.

Image source: https://www.flickr.com/photos/microassist/7268711202/