Write Your Unit Tests Better!

Photo by Clark Tibbs on Unsplash

Unit testing is a crucial aspect of software development, as it helps to ensure that each part of your code works as expected. However, some common pitfalls can hinder the effectiveness of your tests. In this post, we will discuss two of these pitfalls and provide tips on how to avoid them.

Pitfall #1

Rewriting Business Logic in Tests When writing unit tests, it’s essential to test the business logic rather than rewriting it. For example, consider a simple Add method:

public int Add(int a, int b)
{
    return a + b;
}

When we write unit tests, our primary goal is to validate that the business logic performs as expected. If we duplicate the business logic in our test, we’re not genuinely testing the original business logic but rather a replica of it. This can lead to a false sense of security because the test and the business logic might both contain the same mistake, and therefore the test will pass, not catching the error.

Example:

int a = GetRandomInteger();
int b = GetRandomInteger();
int sum = a + b; 

int actualSum = Add(a, b);

Assert.Equal(sum, actualSum);

Here, we are essentially recreating the business logic of the Add method in the test itself. If there was a mistake in the Add method, there's a chance we could replicate that mistake when we write int sum = a + b;. If that happens, our test will still pass, even though the Add method is incorrect.

On the other hand, the approach:

int randomSum = GetRandomInteger();
int randomA = GetRandomInteger();
int predictedB = randomSum - randomA;

int actualSum = Add(randomA, predictedB);

Assert.Equal(randomSum, actualSum);

is much more reliable because it doesn’t replicate the business logic of the Add method. We use subtraction, an entirely different operation, to predict what the result should be. This way, we're not just testing that the Add method can replicate the + operation, but rather that it can produce the correct result in a variety of circumstances.

Pitfall #2: Using Static Values in Tests

Another common mistake is to use static values in tests, which doesn’t cover all possible cases. For example:

int a = 5;
int b = 6;
int sum = 11; 

int actualSum = Add(a, b);
Assert.Equal(sum, actualSum);

This test is valid, but it only ensures that the Add method works with the values 5 and 6. To make your tests more robust, you should use a range of RANDOM values, including edge cases, to ensure your code works in all scenarios.

Summary

In conclusion, avoiding these common pitfalls when writing unit tests can significantly enhance the effectiveness of your tests. By testing the business logic directly and using a range of values, you can ensure your code works as expected in all scenarios. Remember, the goal of unit testing is to catch bugs early and provide confidence that your code works as intended, so invest the time to write effective and meaningful tests.