This is the 4th post on test attributes that were described in the now even more famous “How to test your tests” post. If you want training and/or coaching on testing, contact me.
Accuracy is about pinpointing the location of the failing code. If we know where the offending code is, we can easily analyze what problem we caused, and move on to fixing the problem.
The trivial example is tests that check different methods. Of course, if one of them fails, we know where to look.
Here’s another simple case, on the same method. We have a PositiveCalculator class that its Add method adds two positive numbers, or throws an exception if they are not so positive:
public int Add(int a, int b)
{
if ((a < 0) || (b < 0))
throw new ArgumentException();
return a + b;
}We can then write the following tests:
[Test]public void AddTwoPositiveNumbers_GetResult()
{
PositiveCalculator calculator = new PositiveCalculator();
Assert.That(calculator.Add(2, 2), Is.EqualTo(4));
}
[Test]public void AddTwoNegativeNumbers_Exception()
{
PositiveCalculator calculator = new PositiveCalculator();
Assert.Throws<ArgumentException>
(() => calculator.Add(-5, -5));
}Looking at the tests, we already see they check two different behaviors. When we combine what we read from the tests, and the tested code, it’s easy to relate the parts of the code to each tests. So if one of them fails, we’ll know where to look.
Unfortunately code doesn’t always look like this. It usually starts like that, but then grows to monster-size functions. When it does, it either becomes untestable, or incurs tests that are large, overlap each other, and test multiple things. None of those are accurate tests.
So what can we do?
Let’s start with the preventive measure: Don’t let the code grow. Be merciless about keeping methods small, and use The Single Responsibility Principle to extract code into smaller, easy testable and accurate functions.
But I didn’t write this code!
How do I make my tests accurate?
Here’s what you can do. Now that you have a test, or a bunch of them, it’s time to make use of them: Start refactoring the code. Having the tests in place, will tell you if you’re breaking stuff, and it’s very easy going back to working mode, because refactoring is also done in small steps.
Once you have broken the code into smaller pieces, you can now write smaller tests, which give you the accuracy that the bigger tests didn’t have. In fact, you might want to replace the big tests with some smaller ones, if they give better information and performance for the same coverage.
We can also make the tests more accurate with the following methods:
- One Assert per test – When you check only one thing, chances are that your test is more accurate than when checking multiple things. If you have more Asserts in your tests, break them into multiple tests.
- Test shorter scenarios – In legacy code, it’s tempting to test large scenarios, because the code does a lot, and does not expose entry points to single operations. Try to test shorter scenarios rather than long ones, and smaller objects rather than large one. Try to break long scenarios into short ones. If you use the big tests to refactor the code, you can then write smaller, more accurate tests.
- Mock unrelated stuff- If you have dependencies that do multiple things, and therefore make longer scenarios, mock them. You’ll make the test more accurate because it now runs through the relevant code you’re interested in.
- Check the coverage – Visually if possible. IDEs and tools that show visual coverage on the code are awesome, because they add another visual clue to where the impacted code is. On trivial code they don’t matter much, but on complex code, you can compare paths of different tests, and by applying some elimination, you can find out where the problems are. You can also use the visual paths as feedback to how accurate your tests are, and if they aren’t, make them more so.
Accuracy helps us fix problems quickly. But it’s definitely not so easy to come by, because it depends very much on the tested code. However, using the combination of the methods I suggested, and making use of working to test to refactor and simplifications, test accuracy is definitely within reach.
| Reference: | Test Attribute #4 – Accuracy from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
