Chapter 11. Test Quality
11.6.3. Make Irrelevant Data Clearly Visible
If I can change a value without changing the result of the behavior I want to check, then I call that irrelevant data for this test.
— J. B. Raisenberg
A very frequently performed refactoring consists of changing variable names, and also their values, so that both of these properly reflect their purpose. This is something we have already done in some places when discussing other unit testing issues, but now it is time to take a closer look at this.
This section opens with a quote from J. B. Rainsberger – one that defines a heuristic for recognizing a certain type of (unimportant) test value which should be distinguished clearly from important ones. The following snippet of code illustrates this:
Listing 11.10. Not clear what is important
@Test
public void kidsNotAllowed() {
Person kid = new Person("Johnny", "Mnemonic"); kid.setAge(12);
assertFalse(kid + " is a kid!", kid.isAdult());
}
There is nothing wrong with this test method, except that it is not clear whether firstname and lastname are of any importance to the logic being tested. This can be fixed by giving them values which make them convey the message explicitly: "we are not important, you should not care about us". The code below illustrates how this can be achieved:
Listing 11.11. Irrelevant data clearly visible
@Test
public void kidsNotAllowed() {
Person kid = new Person("ANY_NAME", "ANY_SURNAME"); kid.setAge(12);
assertFalse(kid + " is a kid!", kid.isAdult());
}
I usually use an ANY_ prefix, and capital letters only - but this is just one possible instance of how one might do this. Find something which looks good for you.
Apart from reading the test code more easily, another advantage is that if the test fails, the error message will also clearly show what is important:
Listing 11.12. Error message shows what is irrelevant
java.lang.AssertionError:
Person{firstname='ANY_NAME', lastname='ANY_SURNAME', age=12} is a kid!
In the event of a value like this being used repeatedly in multiple test methods, I would suggest extracting it as a constant (as you should always do), as well as naming it appropriately:
258
Chapter 11. Test Quality
Listing 11.13. Irrelevant data expressed by both variable names and values
private static final String ANY_NAME = "ANY_NAME"; private static final String ANY_SURNAME = "ANY_SURNAME";
@Test
public void kidsNotAllowed() {
Person kid = new Person(ANY_NAME, ANY_SURNAME); kid.setAge(12);
assertFalse(kid + " is a kid!", kid.isAdult());
}
This renaming of constants is especially important for values other than String, so you can have variables
like: ANY_VALID_POST_CODE, ANY_NUMBER, ANY_DATE, etc.
In fact, there is no need to wait for the refactoring phase to make irrelevant data clearly visible. When writing a test you should be clear in your mind about which data is important for the scenario you are covering with that test. This is probably the best time to introduce names of variables and values along the lines discussed in this section.
11.6.4. Do not Test Many Things at Once
The tests we have written so far have been pretty focused: they have verified only one thing. However, it often happens that this is not the case. An example of a test which verifies more than a decent test should is presented below.
Listing 11.14. Testing two scenarios at once
@RunWith(JUnitParamsRunner.class) public class PhoneSearchTest {
public Object[] data() {
return $($("48", true), $("+48", true), $("++48", true), $("+48503", true), $("+4", false), $("++4", false),
$("", false), $(null, false), $(" ", false)
);
}
@Parameters(method = "data") @Test
public void testPrefixVerification(String prefix, boolean expected) { PhoneSearch ps = new PhoneSearch(prefix);
assertEquals(expected, ps.isValid());
}
}
The problems with this test are the following:
•When it fails, it will not be instantly clear which feature is not working. Is the PhoneSearch class able to recognize valid prefixes? Is it able to reject invalid prefixes? Which one of these two works, and which does not?
•The name of the test method (testPrefixVerification()) is too generic. What exactly is being tested? Likewise, the name of the data provider (data()) does not reveal its intent clearly enough.
•The test is more complicated than it should be: it uses a boolean flag parameter to decide whether the assertion should pass or fail. This amounts to introducing a form of logic into the test code - something
259
Chapter 11. Test Quality
which, as we discussed in Section 10.2, is very bad indeed! That design decision forces us to make use of the assertEquals() assertion method, which is also the most generic one of all.
You can see the refactored version of this test in the next two listings:
Listing 11.15. Refactored test - testing valid prefixes
public Object[] validPrefixes() {
return $("48", "48123", "+48", "++48", "+48503");
}
@Parameters(method = "validPrefixes") @Test
public void shouldRecognizeValidPrefixes(String validPrefix) { PhoneSearch ps = new PhoneSearch(validPrefix);
assertTrue(ps.isValid());
}
Listing 11.16. Refactored test - testing invalid prefixes
public Object[][] invalidPrefixes() { return new Object[][]{{"+4"}, {"++4"},
{""}, {null}, {" "}};
}
@Parameters(method = "invalidPrefixes") @Test
public void shouldRejectInvalidPrefixes(String invalidPrefix) { PhoneSearch ps = new PhoneSearch(invalidPrefix);
assertFalse(ps.isValid());
}
This version of the test differs in the following respects:
•There are two test methods now - one verifies whether the SUT accepts valid prefixes, the other whether the SUT rejects invalid prefixes.
•The boolean flag has been removed.
•assertEquals() has been replaced with more intention-revealing assertions - assertTrue() and
assertFalse().
•Each test method has its own data provider.
•The names of all methods, including data providers, have been updated so they are more intentionrevealing.
Even if the test has grown in length, it seems to be of higher quality now. When looking at the test code it is easier to deduce "what are the prefixes that PhoneSearch accepts?", so the documentation aspect has also been improved. Likewise, if this test fails, you will know which part of the SUT’s code needs to be fixed.
11.6.5. Change Order of Methods
In order to improve the readability of tests, I often rearange the order of methods so they are consistent across many tests. This is a simple refactoring, which introduces no risk of breaking anything. The gain
260
Chapter 11. Test Quality
is that it is much easier to browse test code, because you always know where to expect certain things. In my example, all test classes have the following structure:
•private fields,
•data providers,
•set-up methods,
•test methods,
•private methods.
I rarely deviate from this pattern. Only occasionally do I move a data provider method next to the test method which uses it (but especially if only one test method uses this data provider).
You can usually impose the structure you want while writing the tests. There is no need to wait for the refactoring phase to do this.
11.6.6. Do not Go Too Far
The goal of refactoring unit tests is slightly different from refactoring mainline code. For the latter, your goal is to modularize the codebase and eliminate tightly coupled relationships. For unit tests, those goals are secondary to creating simple, human-readable tests.
— Keith D Gregory
You might have noticed that so far we have not discussed some very popular refactorings that we use quite often when working with production code. For example, we have not even mentioned Extract Method22 refactoring, which seems to be the most popular (and probably the most powerful) of all. There is a good reason for this, which we shall now discuss.
In general, code redundancy is a bad thing. In the course of the book so far, we have on several occasions discussed the importance of the DRY principle (and not without good reason). However, things are not so black-and-white when it comes to test code. As was discussed previously, test code should be as simple as possible. It should be readable, and free of any logic, so it does not contain any bugs, and can serve as a living documentation of the production code. Because of these expectations, some refactorings well-suited to production code ought to be considered less useful for test code.
Sometimes it is very easy (and thus tempting!) to make the test code more concise by grouping things within a private utility helper method. If there are one or two methods like this in a test class, it is not so bad. However, I have witnessed a lot of really unreadable test code, which required me to jump through many tangled private methods to understand any one single test method. This is unacceptable. What is still more horrific is the use of template methods and abstract test classes, which, in conjunction with such utility methods, can make test classes completely unreadable.
In production code, you can almost always bet on DRY and win. In the case of test code, you need to strike a balance between the DRY principle and the expressiveness of tests.
I have to admit that many people see it differently. I have read many blog posts which promote excessive use of private helper methods, and test class hierarchies. My point of view is different, and I would
22See http://martinfowler.com/refactoring/catalog/extractMethod.html
261