Unity Unit Testing Advanced Tutorial – CI, Patterns, IDE Support & More

Jun 7, 2020 Stas Korotaev unity

In the previous post I’ve covered the essentials of Unit Testing and NUnit in Unity and now let’s get into things that can help speed up and improve the process.

I’ll go over useful attributes and asserts, naming conventions, and how to run tests from the IDE and the command line.
But first, let’s cover the common pattern when writing unit tests.

Arrange, Act, Assert (AAA Pattern)

The idea is that you split each testing method into three parts to better structure them.
In Arrange you would first set up what you need to then do the actual test: create mocks, create the object that is tested, etc.
Then the Act part is the actual calling the methods or anything else you are testing.
And finally, in the Assert part you would check the expectations are met (in our case using the Assert API from NUnit. Like Assert.That , Assert.AreEqual and others)

 1// arrange
 2var splitter = new StringSplitter();
 3var str = "hello_world";
 4
 5// act
 6string[] splitted = splitter.split(str, '_');
 7
 8// assert
 9Assert.AreEqual(2, splitted.Length);
10Assert.AreEqual("hello", splitted[0]);
11Assert.AreEqual("world", splitted[1]);

Useful Asserts

You could write all your tests with just Assert.That, but when tests fail it is really useful to see errors like:

Expected: 1234
But was: 123

which can instantly give you a hint of what went wrong without re-running the tests with debugger enabled to look at what the variables actually were.
You could write those messages each time yourself, like:

1Assert.That(a == b, $“Expected: {b} But was: {a}”);

But these can easily be generated for you by doing

1Assert.AreEqual(b, a);

This is the classic model of writing assertions and there are a lot more, for example: Assert.NotNull, Assert.Contains, Assert.Throws.

Constraint Model

Even though the classic model is still supported, it will not get new features, and the current one is the constraint model that uses Constraint objects.
Here you will still be using the Assert.That, but a different overload of the method. For example:

1Assert.That(str, Is.EqualTo("hello"));

Is is just one of the static helper classes that allow you to get to the actual constraint classes, it also helps it be more readable in the process. There is also a Has class with more options.

Because all constraints implement the IResolveConstraint interface, and Assert.That expects it as a second parameter, you can create your own constraints, when you couldn’t add new methods to the Assert class in the classic model.

This also fixes a pet peeve of mine – in the classical model you always need to remember to put an ‘expected’ result first in the Assert.AreEquals which I find counter-intuitive.

Method Naming Conventions

One of the most common naming strategies for methods was introduced by Roy Osherove and the idea is to mention:

the unit of work (the name of the tested method)
state or input
the expected behavior

with underscores in between.
It looks like this:

1Split_EmptyString_ThrowsException()
2Remove_FromEmptyCollection_DoesNotThrow()
3SubtractMoney_FromZero_ReturnsFalse()

The motivation is to specify requirements you will be checking by this method. That may be technical requirements, for example, set by the interfaces the class implements. Or business requirements.

This naming also allows you to understand what may have gone wrong after your changes, from just looking at the failed test method name.

But there are also other naming conventions. You don’t have to follow any of them, but it is useful to look at them and their motivation before deciding on what will you use. And especially if working in a small team or on a small project – don’t overcomplicate it.

Useful Attributes

Aside from attributes that are actually required to run your tests and [SetUp], [TearDown] I’ve covered in the previous article, NUnit provides more attributes that can simplify your test writing process.

TestCase

When you want to test that your methods give correct results for different input data, the TestCast attribute may come in handy. This is one of the ways to write parameterized tests in NUnit.

1[TestCase(1, 1, ExpectedResult = 2)]
2[TestCase(0, 0, ExpectedResult = 0)]
3[TestCase(1, 0, ExpectedResult = 10)]
4public int Sum(int first, int second)
5{
6    return first + second;
7}

In the example above the last testcase fails. All test cases will appear in the TestRunner as separate lines, so you will see which exact one failed and why.