Before we get into unit testing we should ask ourselves why would anyone write code to test other code? Is there any reason to do that extra work? It turns out that there are many reasons for that. Firstly, you’re going to make sure that given function works as expected. Secondly, if you decide to change the function, you still have it tested, so in case of some incorrect change you’ll know immediately that something is wrong. Thirdly, your code will have better design, because (once you figure it out) you’ll most likely avoid all dependencies and you’ll make sure that your code is as easy to use as possible.

What is unit testing?

You take smallest possible piece of code (a unit) and test it. Commonly the smallest possible unit is function. Each test should be indepenedent of others and should only test only one thing.

You should run tests periodically, in some cases it’s possible to make your environment run your tests after each code change. I also like to double check my code by running tests before I push them, so whenever someone downloads my code works as expected (at least in terms of tests ;P). If you use continous integration you should configure it to run all tests once a new commit comes in.

Most languages have some kind of unit testing framework. This article focuses on xUnit.Net.

TDD

Test Driven Development (TDD) is a way of writing software. It’s not the same as unit testing. TDD is how you “drive” the process. The principle is that you firstly write test, then you write a piece of code (method/function), then you run the test. Once you do that you write code to make the test pass.

We call this pattern of working RED-GREEN-REFACTOR. RED because you write test which fails firstly. It’s because you want to make sure that the test works correctly. It results in error obviously (which is usually marked by red color). GREEN stands for test which has passed, because at this stage we write minimum code to make the test pass (similary the passed test is usually marked by green color). The third stage is REFACTOR which means that we improve code quality. Once we’re satisfied with results we go on to create next tests. In so doing our development process is driven by tests.

RED-GREEN-REFACTOR

This is the bare minimum about TDD. TDD can also include lots of different tests e.g. acceptance tests, integration tests. While you should familiarize yourself with TDD, it’s not the main point of this post. Here I’ll teach you how to create basic unit tests for your code.

Getting started

Let’s start by creating new solution with two projects. First project will be “Class Library (.NET Core)” (I named it ECommerce) and second will be “xUnit Test Project (.NET Core)” (I named it ECommerce.Tests).

Then add your library project as a reference to your xUnit project (refer to screenshot below).

Visual Studio Add A Reference

Rename Class1 to ShoppingCart and UnitTest1 to ShoppingCartTest. We’re ready to go!

Your task is to create a class which will handle shopping cart calculations. It holds a number of items. Each item has a net price (price without VAT), VAT (percent) and quantity. Cart calculates total net value, total VAT value and a total value to pay (net price + VAT). Whole class is listed below. I haven’t included calculations, those I’ve left for you to complete.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

public class ShoppingCart
{
    public List Items { get; } = new List();

    public void Add(string name, double netPrice, int quantity, double vatPercent)
    {
        Items.Add(new Item
        {
            Name = name,
            NetPrice = netPrice,
            Quantity = quantity,
            VatPercent = vatPercent
        });
    }

    // TODO IMPLEMENT ME!
    public double TotalNetValue => 0;

    // TODO IMPLEMENT ME!
    public double TotalVatValue => 0;

    public class Item
    {
        public string Name { get; set; }

        public double NetPrice { get; set; }

        public int Quantity { get; set; }

        public double VatPercent { get; set; }

        // TODO IMPLEMENT ME!
        public double NetValue => 0;

        // TODO IMPLEMENT ME!
        public double VatValue => 0;
    }
}

Your first test

Each test is a function inside ShoppingCartTest class with a Fact or a Theory attribute. We’ll start with a Fact because it’s the most basic.

Our first test will check if our class correctly calculates total net value of a shopping cart. We’ll start by creating shopping cart, adding item into it, calculating expected value and checking if shopping cart returned correct value.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[Fact]
public void Correctly_Calculates_Total_Net_Value_For_One_Item()
{
    var cart = new ShoppingCart();
    cart.Add("HardcoreProgrammer Book I", 999.99, 1, 0.08);

    var expectedNetValue = 999.99;

    Assert.Equal(expectedNetValue, cart.TotalNetValue);
}

Now, run the test by clicking “Run All” inside “Tests Explorer” window or by right clicking and choosing “Run tests” (you can also use following shortcut CTRL+R,T).

OK, it failed. It’s your turn, go back and make ShoppingCart.TotalNetValue return correct value.

Got it? Great, rerun the test to make sure it works correctly. Make another test to check wheter your changes work when quantity of an item is bigger than 1.

Your first theory

This time we’re going to check wheter or not our code correctly calculates VAT value. Let’s write another test. It’s somewhat similar to previous one, but instead of a plain sum we’re going to sum calculated VAT values.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

[Fact]
public void Correctly_Calculates_Total_Vat_Value()
{
    var cart = new ShoppingCart();
    cart.Add("HardcoreProgrammer Book I", 999.99, 1, 0.08);
    // we know that this is the value it should produce for this item
    // vat value = price * vat_percent, round to two decimal places
    var expectedVatValue = Math.Round(999.99 * 0.08, 2);

    Assert.Equal(expectedVatValue, cart.TotalVatValue);
}

Again run the test, fix ShoppingCart.TotalNetValue and rerun the test.

Let’s stop for a moment and think about it. We’re only testing one item (by means of quantity). We want to make sure that then calculations are correct when someone adds 1 piece of item or more. This example may be a bit far fetched, but technically you’d want to check a couple of cases sometimes using same tests. For this you use a Theory, basically you can create a tests and supply with with different arguments to check different cases.

To do that we’re going to replace Fact with a Theory. Theory needs a set of data, we will supply the data via InlineData attributes. Once we’re done with we’re going to edit our test method to receive data (via parameters). This requires only a couple of changes.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

[Theory]
[InlineData("HardcoreProgrammer Book I", 999.99, 1, 0.08)]
[InlineData("HardcoreProgrammer Book II", 999.99, 2, 0.08)]
[InlineData("None", 1, 1, 0.0)]
[InlineData("Flamethrower", 0.99, 10, 0.23)]
public void Correctly_Calculates_Total_Vat_Value(string name, double netPrice, int quantity, double vatPercent)
{
    var cart = new ShoppingCart();
    cart.Add(name, netPrice, quantity, vatPercent);

    // we know that this is correct way of calculating a vat value
    var expectedVatValue = Math.Round(netPrice * quantity * vatPercent, 2);

    Assert.Equal(expectedVatValue, cart.TotalVatValue);
}

Arrange – Act – Assert pattern

Did you notice that above tests are created in similar fashion? We call it Arrange – Act – Assert (also known as AAA) which is a pattern for writing unit tests. It divides a test into 3 sections. Each one with separate set of responsibilities.

We use the first section “Arrange” to prepare (arrange) all data needed to run the tests.

Second section “Act” runs (act on) the the code under test.

We use the last section “Assert” verify (assert) the results.

The AAA helps separate setup, the thing being tested and the verification process.

Take a look at our previous test again to see how to works:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

[Theory]
[InlineData("HardcoreProgrammer Book I", 999.99, 1, 0.08)]
[InlineData("HardcoreProgrammer Book II", 999.99, 2, 0.08)]
[InlineData("None", 1, 1, 0.0)]
[InlineData("Flamethrower", 0.99, 10, 0.23)]
public void Correctly_Calculates_Total_Vat_Value(string name, double netPrice, int quantity, double vatPercent)
{
    // ARRANGE
    var cart = new ShoppingCart();
    cart.Add(name, netPrice, quantity, vatPercent);

    // ACT
    var expectedVatValue = Math.Round(netPrice * quantity * vatPercent, 2);

    // ASSERT
    Assert.Equal(expectedVatValue, cart.TotalVatValue);
}

Assertions

I’ve only introduced you to a couple of assertions. Let’s take a look at other available assertions for our unit testing needs.

  • Null and NotNull to check wheter object is empty or not
  • Equal and NotEqual to check wheter objects are equal or not (hint: it also works for collections)
  • True and False to check result state
  • Empty and NotEmpty to check wheter enumerable is empty or not
  • Contains and DoesNotContains to check wheter enumerable contains value (hint: it also works for strings)
  • Single to check wheter enumerable contains only one element
  • Throws to verify that a method throws exception

More tests

We should always pay attention to edge cases. Unit testing works nicely in this regard e.g. when you have a method which does some calculations you could write a regular test case, a test case which could check division by 0 and a case which check wheter or not a variable is beyond certain range (it is negative or user tries to withraw more that 100% of money from bank account).

There are still some cases which could (probably) break your code. There is still some more work to do. In similar manner, write a tests and then try to fix your code for following edge cases:

  • it should throw ArgumentOutOfRangeException when vat is less than 0 or more than 100%
  • ShoppingCart should throw ArgumentOutOfRangeException when product price is less than 0
  • it should throw InvalidOperationException when you add an item with negative quantity
  • ShoppingCart should limit maximum quantity of one item to 10 (we want to make sure that one user won’t take whole stock in one go), so if user tries to add more than 10 we trim it down to 10

Qualities of a good unit test

There are a few qualities which designates a good unit test. Let’s take a look at some basic traits of quality unit tests.

  1. Single unit test should test one unit of code (most likely a method), hence the name “unit test”. If you test more than one method then you have multiple points of (possible) failure, so you cannot be sure what exacly failed.
  2. Unit tests should be independent. By this I mean that it does not depend on environment, so other software developers can run it without additional setup.
  3. Good tests should not depend on other test. Each test is independent, so you know exacly what failed and what not. If the tests are interdependent then one failed test can cause all other tests to fail, in this case how would you know which test is broken?
  4. It should be easy to understand. By this I mean mostly that you should follow Arrange – Act – Assert pattern. You’ll have clear division of what is going on. This also means that your tests will be rather short. If your test is long or complicated then something most likely is wrong (consider the test and the thing being tested, maybe code design needs some thinking).
  5. Unit tests should be fast. Number of tests depends on the size of your code base and your will to create the tests. Potentialy you can create thousands of these. You don’t really want to make tests that run really long. Fast tests ensure faster feedback loop.

Practicing TDD and unit testing using code kata

If you want to get some practice with TDD and testing then you can do some code katas. Code katas are software development practice sessions. You take some problem and try to solve it.

This practice is useful when you want to learn to solve new problems, get acquainted with TDD or learn new programming language.

The best part of it is that code katas work for any language and you get to learn certain way of thinking and analysing problems.

You can start with String calculator by Roy Osherove. You can also find some more at codekata.com.

If you want to read more about kata then head on to Kata – the only way to learn TDD.

Summary

As you can see basic unit testing is fairly simple. Some may argue that unit testing takes too much time. It takes some time, but we need to think of it in terms of return of investment. If you test something now then it will produce less errors in the future. I myself am not advocating 100% coverage (meaning that whole code is covered by tests). It depends on project, but in terms of common sense you could just test 20% of most important code or 20% of code which produces most bugs. While the opinions on this matter are many this is just an introduction, learn the basics and then try some more advanced stuff and different opproaches.