I one of my previous post I said I’m going to write a series of articles on xUnit. I’m going to start from the begging which is installing xUnit packages. I’m also going to explain a little about other frameworks that might be used with xUnit to complement it. In the future I’ll go in more depth into those framework and best practices surrounding those.

Lastly we’re going to propose some practical approach into unit testing and when it’s best to use them. Partly because there’s a lot of different opinion out there and none of them are entirely incorrect. Because based on the company and particular situation that we’re in, we might need to make different decision about how to best test a code base.

What is Unit Test and How does it Differ from Other Types of Tests

It helps to first have a look at different types of tests. There might be other types of tests, but I’m speaking mainly from a developer perspective.

Unit Test

Unit test is the most common types of tests. The word Unit here means that we test one unit at a time. Here an example, suppose we have a class which has dependencies on other classes to do its job. We want to test that class but not its dependencies. So we have to somehow isolate that class and pass fake objects for its dependencies to be able to focus on testing the Unit at hand and not its dependencies. This unit most of the time is called System Under Test or SUT for short.

Integration Test

The integration test is differ from Unit test in that it tests multiple unit that work together to achieve a goal. So in the integration test context we test a class in a more functional way with its dependencies. The reason integration test are less done than unit tests are that they are expensive. The reason is that setting them up are more involved and sometimes they require more resources to run. But there are some situations that make them more suitable comparing to unit tests. That doesn’t mean we have to choose one, we can write both for our code. What I’m trying to say is that sometimes the value of one of them highly overpower the value of the other.

Functional UI Test

This type of test is not written most of the time by developers, but testers. Functional UI Test is testing the application from the usability and UX perspective. So it has the highest level among different kinds of test. This kind of the require even more resources than an integration test but has the most value. Because if we pass this phase we have the most confidence that our code is resulting is an application that actually solve the customer’s problem.

Installing the xUnit Packages

The first step we need to take is to add the necessary project to start testing. We can install the packages on the same project that has the files that we want to test. We can also create a new project for the purpose of testing. I choose the later most of the time.

We can directly create an xUnit project through the project template if this template has everything we need. Or we can create a library project and add the necessary package.

The first xUnit project in the template, is the same as this library with these three packages preinstalled.

• Microsoft.NET.Test.Sdk
• xunit
• xunit.runner.visualstudio

Most of the time the first approach cover our need. But if we have no use for these preinstalled packages, then we can start off with a .Net Core library project.

Writing Your First xUnit Unit Test

Let’s add a very simple test for a class called HomeController. I’ll include a working sample that contains these code in the summary section. Suppose this class is our SUT.

Here’s our simple test for this class.

Normally the method that tests the something has three part. But I chose four part naming. The reason is that it makes finding tests and run them easier since I I think the visual studio test explorer leave a lot to be desired. Let’s have a look at HomeController_Index_Always_ReturnTheCorrectType. The first part is the name of the class that we’re testing. The second part is the method of that class that we want to test. The third part is the condition under which our test should pass. For example here’s it Always but it could be IsAdmin or something like that. The last part is our expectation, in other word the thing that we expect to happen when we ran the action.

Complementary Tools Used with xUnit

There some frameworks that can be used along with xUnit to ease the process. Here’s I list some of those with a brief summary about them.

• Mocking Frameworks/Isolation Frameworks: These frameworks are used to isolate our unit test from its dependency. There are a lot of frameworks that can be used to achieve this, but the most popular one are Moq, FakeitEasy, NSubstitute etc.
• Assertion Helpers: These kind of libraries make our assertions more readable as if we constructed a sentence. One of such library is Fluent Assertions.
• Data driven: These libraries are useful to supplement fake data for us so we don’t have to waste time filling object with values before testing. One such library is AutoFixture.

Some Practical Advice for Testing

There are many different ways of going about testing a piece of code. Sometime tests even comes before the actual code like TDD. So what I’m about to say here is subjective and dependent on the approach that we’re taking. The first thing to consider is testing the code that worth testing. Some code are very simple and there’s really not worth testing. Take this piece of test for example.

This test is created to have a very simple example. In the real world method such as this or for example getters to setters should not be tested. Unit tests is important when our code have some complicated logic with no side effect. Another thing to consider is when we have to actually choose between unit test and integration test.

This can happen if we have a deadline to meet or simply want to have a minimum viable product and we’re not interested in having a complete suit of tests. Most of the time for business driven application an integration test has more value comparing to unit test. For example a class that has a lot of dependencies to do something, but what it does and what their dependencies do are not complicated, it better suited for an integration test.

I’m just introducing some ideas because tests are the first thing that get overlooked when we’re in any type of time pressure.

Summary

This post was an introduction to start using the xUnit framework. We saw what different types of tests are, then we created the necessary project to start testing. I also explained some complementary tools that can be used when we unit test. Lastly I went through some practical advise which was more opinion based and situational, but worth mentioning nevertheless. The examples in this post are very simple but I’ve created a sample project for good measure, you can find it here.