The Unit Testing Code Model

There is a widely established model for writing unit tests called “Arrange, Act, Assert,” and it keeps your tests short and clean.

Essentially what you’re doing is breaking up your test into those three parts.  It makes it easier for you to write, and easier for other devs running your tests (or using them as code samples for their own work) to follow.  I take the time to decorate every one of my tests with these sections.  Most devs don’t, but I think it’s worth the effort and provides cleanliness rather than clutter.

Here’s what that looks like:

private int MultiplyTwoNumbers(int first, int second)
    return first * second;
public void MultiplyTwoNumbers_TwoIntegers_ResultIsCorrect()
    // Arrange
    int a = 5;
    int b = 6;
    int expectedResult = 30;  // 5 x 6 = 30
    // Act
    int actualResult = MultiplyTwoNumbers(a, b);
    // Assert
    Assert.AreEqual(expectedResult, actualResult, "The numbers were not multiplied correctly");

You see how the insertion of the section header comments makes it easy to follow?  A dev who ran the test but was unsure of what exactly was being tested could start at the very bottom, where the Assert (the check) happens.  A dev who wanted to see how to call your Multiply method could start at the “Act” line for a concrete code example.

This also encourages you to keep your tests short and focused.  Get in and get out.

Using the “Arrange, Act, Assert” approach is widely understood as a best practice; there’s no real downside, other than having to type a bit more.


What’s a Unit Test?

A unit test is an automated (read: coded) test that executes a small block of code (the unit), expecting a certain result, and comparing what actually comes out with that expected result.

Let’s say I created a method that multiplies two integers together:

public int MultiplyTwoIntegers(int a, int b)
    return 0;

I haven’t put the logic in place yet.

My unit test should cover the expectations of various use cases.  So what are some use cases for a method like this?  Well, one would be I put in two integers, and I get back the value of those two integers multiplied together.

That test would look something like this:

public void MultiplyTwoIntegers_TwoPositiveIntegers_IntegersAreMultipliedCorrectly()
 // Arrange
 int a = 5;
 int b = 10
 int expectedResult = 50;
 int actualResult;
 // Act
 actualResult = MultiplyTwoIntegers(a, b);
 // Assert
 Assert.AreEqual(expectedResult, actualResult);

Pretty simple.  I set up a couple of integers to test with, set up what I know the correct result is, then call the method, then compare what came back from the method with what I know that correct result is.  If the “Assert” is false, the test fails.  If the Assert is true, the test passes.

This test would fail right now, because I haven’t put in the logic for the multiplication yet.  I’m just returning 0.  So when I run it, the Assert will compare the expected (50) with the actual (0) and blow up.

If I go back now and change the logic to this:

    return a * b;

Then re-run my test, the Assert will succeed and the test will now pass.

There are some details here that I won’t go over now, like the name of the test, how you set it up, how you run it, etc.  The point I’m trying to get across is that this is a basic unit test:  You can run it again and again, it will run quickly and it will succeed every time, unless the logic in the method gets changed.

Why a Blog on Testing?

As a .Net developer I’ve had an interest in unit tests for several years, but only recently have gotten to the point where I’m getting decent at it, testing as I go, or even – GASP – before I write any code.

As it’s become more a part of my normal tasks, I’ve started to realize just how valuable it can be, and that’s led to a conscience about writing code without tests in place; in the back of my head I know when I’ve got code in there that doesn’t have tests on it and I feel pangs of guilt until those tests get written.

I also know that most developers don’t like unit tests, don’t write ’em, and don’t care.  Honestly, every shop wants you cranking out code as quickly as you can, and tests often seem to be a luxury, so few dev’s bother to learn how to do them right or at all.

So call me the voice in the wilderness.  I want to evangelize testing as much as I can to my developer brethren.  Because it’s the right thing to do.

I’m not an expert.  I have enough knowledge to be able to write about the process for awhile, and that’s what I’m going to do to get started.

But I’m also moving into a different and exciting area of programming in my own career, more front-end, including Angular, and I’m very interested to learn how to test there, too, so on this blog we’ll talk about those concepts as I learn them, too.

I hope to make this blog fun and interesting, and to learn a lot along the way.  I invite you to join me.