The data used in tests is very important and, although the topic of this post seems very obvious, I’ve run into problems because of it quite a few times, so I think it’s worth spending at least a few lines on it.

There are several important things to keep in mind when defining data for our automated tests. In this post I’ll focus on three mistakes I come across often:

  • Different data with the same values
  • Too much data the test doesn’t need
  • Using data that leads to confusion

Different data with the same values

This problem shows up especially with numeric data, since it’s the most likely to be repeated in tests. Let’s say we want to test a method that divides two numbers and returns the result (a very original example, huh? ;P). A clear example of a test with bad data would be this:

[Test]
public void Divide() {
    var result = Divide(2, 2);
    result.Should().Be(1);
}

Given the data in this test, it’s perfectly possible to mix up the dividend and the divisor, because swapping them gives the same result. Not only does it make the test harder to read, an implementation could give us a false green.

Obviously this example is very basic, but this kind of mistake is made quite often when we have numeric identifiers, values expressing quantities, or dates. It’s typical to use “1” as a numeric identifier, but when we have to write a test with the user with id 1 from company 1, it’s very important to stop for a few seconds and look for data that can’t be confused.

Too much data the test doesn’t need

Another common problem is providing more data than strictly necessary for the goal of our test. If we’re writing tests to verify an API that can receive several parameters, some required and some optional, it’s a good idea to create several tests covering everything from the most basic scenario to the most complex ones. Let’s say we have a discount calculator for clients that needs to receive a client with an identifier, country of origin and activity in order to calculate their discount.

var client = GivenAClient (Id:1, Name:"Peter", Country:"Spain", Activity:"Development", Sector:"Software");
discountCalculator.CalculateFor(client);

Reading this example, it looks like a client needs all the fields to calculate a discount, but we’re specifying the sector and it turns out it was irrelevant; our eagerness for reuse has played a trick on us. If we assume our tests can serve as documentation for other developers (or even for our future selves), the more concise we are with this information, the better.

Using data that leads to confusion

Other times we have data that must be present but whose value is irrelevant to the test. It’s important for the test to make it clear that we don’t care about the value and that it doesn’t affect the test. Here the consequences can be similar to the previous point, since the test can be confusing to read.

var client = GivenAClient (Id:1, Name:"Peter", Country:"Spain", Activity:"Development");
discountCalculator.CalculateFor(client);

Reading this code we might think the country and the activity are relevant to the discount calculation just because we’re using specific values. But what if we use generic values except when the value really matters?

var client = GivenAClient (Id:Any.Id, Name:Any.Name, Country:"Spain", Activity:Any.Activity);
discountCalculator.CalculateFor(client);

With this small change, the information relevant to the test becomes much clearer, and both our teammates and our future selves will really appreciate it.