We are not perfect and therefore we make mistakes but we need to be able to find those mistakes before they get into releases and/or production. Therefore it has been increasingly important to be able to test our code and solve any issues that those Unit tests may indicate. In order to make our life somewhat easier we use certain frameworks and libraries. I will talk more about nUnit and Moq today.
nUnit
Well, it’s a framework for unit testing our code. It is reach and one of the best to test C# code. nUnit is available both as a separate download, as well as a NuGet package via NuGet Package Manager in Visual Studio. A best practice is to create a separate project in your Visual Studio for unit testing, essentially for each project you should have a unit test project. In order to make your class available to test by the nUnit system you have to use the TestFixture attribute above your class, that is [TestFixture]. Methods can become meaningful test by using the attribute [Test] before the method.
You should be careful with naming the tests, their name should represent exactly what you’re testing so far an outside person becomes immediately known what you’re doing. It should follow a general convention of “Given something it should happen this”. Now there are 2 styles, either with an underscore separating each word or without, I generally prefer the last.
I will introduce two more attributes, that is [SetUp] and [TearDown]. [SetUp] is used for a method that is executed before each of your tests, this is particularly useful if you want to (re)initialize data(collections, variables etc.) that you are changing during the unit tests. [TearDown] is mostly used to destroy/clean and it’s executed after each test.
Another useful attribute is [Ignore(reason/comment)], that is used for ignoring a certain test, for various reasons(e.g. faulty library on the deploying machine).
The structure of a unit test should more or less follow this convention, also called AAA – Arrange, Act, Assert which means that firstly you have to create all dependencies, run your method under test and verify if the requirements are met (e.g. certain variable has a certain value, throws exception).
[spoiler title = “Sample unit test”]
[Test]
public void DataSentIsReceivedCorrectlyByTCPServer()
{
_server.StartAsync(ip.ToString(), port);
var listener = new TcpClient(ip.ToString(), port);
Thread.Sleep(1000);
var rnd = new Random();
var itemToBeSent = rnd.Next(0, 1000);
listener.Client.Send(BitConverter.GetBytes(itemToBeSent));
Thread.Sleep(1000);
var itemReceived = _server.Dequeue();
Assert.That(itemReceived == itemToBeSent);
}
[/spoiler]
In case you’re asking yourself, you can freely use async and await in unit test for nUnit versions above 2.6.2 and make changes accordingly(instead of returning void you have to return an async Task).
Moq
When we have more complex classes to tests, sometimes it becomes hard and unnecessary to create instances of complex objects. That’s where Moq kicks in: Moq is a library that essentially mocks objects(stubs as they are called) that can be used to call methods with. Installation steps are the same as for nUnit. Moq is one of the libraries that takes advantage of LINQ and you can mock both classes as well as interfaces.
[spoiler = “sample mocking]
Mock<ILogger> _logger = new Mock<ILogger>(MockBehavior.Loose);
[/spoiler]
In order to access the actual instance of the object you can do it via the Object property. Also Moq is pretty clever and does recursive mocking, for instance if you have a complex class that contains more complex types(other classes), the library mocks those underlying objects as well. You can use Moq library to test for return values, if a certain method is called with certain parameters, if a method throws exception etc).
Here you can find a quick start on how to use Moq in your unit tests.
