In my opinion, Unit tests should be well structured and written even better than production code.
In fact, Unit Tests act as a first level of documentation of what your code does and, if written properly, can be the key to fixing bugs quickly and without adding regressions.
One way to improve readability is by grouping similar tests that only differ by the initial input but whose behaviour is the same.
Let's use a dummy example: some tests on a simple Calculator
class that only performs sums on int values.
public static class Calculator
{
public static int Sum(int first, int second) => first + second;
}
One way to create tests is by creating one test for each possible combination of values:
public class SumTests
{
[Test]
public void SumPositiveNumbers()
{
var result = Calculator.Sum(1, 5);
Assert.That(result, Is.EqualTo(6));
}
[Test]
public void SumNegativeNumbers()
{
var result = Calculator.Sum(-1, -5);
Assert.That(result, Is.EqualTo(-6));
}
[Test]
public void SumWithZero()
{
var result = Calculator.Sum(1, 0);
Assert.That(result, Is.EqualTo(1));
}
}
However, it's not a good idea: you'll end up with lots of identical tests (DRY, remember?) that add little to no value to the test suite. Also, this approach forces you to add a new test method to every new kind of test that pops into your mind.
When possible, we should generalize it. With NUnit, we can use the TestCase
attribute to specify the list of parameters passed in input to our test method, including the expected result.
We can then simplify the whole test class by creating only one method that accepts the different cases in input and runs tests on those values.
[Test]
[TestCase(1, 5, 6)]
[TestCase(-1, -5, -6)]
[TestCase(1, 0, 1)]
public void SumWorksCorrectly(int first, int second, int expected)
{
var result = Calculator.Sum(first, second);
Assert.That(result, Is.EqualTo(expected));
}
By using TestCase
, you can cover different cases by simply adding a new case without creating new methods.
Clearly, don't abuse it: use it only to group methods with similar behaviour - and don't add if
statements in the test method!
There is a more advanced way to create a TestCase in NUnit, named TestCaseSource
- but we will talk about it in a future C# tip π
Further readings
If you are using NUnit, I suggest you read this article about custom equality checks - you might find it handy in your code!
π C# Tip: Use custom Equality comparers in Nunit tests | Code4IT
This article first appeared on Code4IT π§
Wrapping up
I hope you enjoyed this article! Let's keep in touch on Twitter or LinkedIn! π€π€
Happy coding!
π§