Practical Test-Driven Development using C# 7

I was first introduced to TDD about five years ago. I was interviewing for a lead developer position for a small startup. During the interview process, the CTO mentioned that the development team was practicing TDD. I informed him that I didn't have any practical TDD experience, but that I was sure I could adapt.

In all honesty, I was bit nervous. Up to that point, I had never even written a single unit test! What had I gotten myself into? An offer was extended and I accepted. Once I joined the small company I was told that, while TDD was the goal, they weren't quite there yet. Phew; crisis averted. However, I was still intrigued. It wasn't until a few months later that the team delved into the world of TDD, and the rest, as they say, is history.

My introduction to TDD is a little different from John's. I have been writing code since I was in middle school in the early 1990s. From then until 2010, I always struggled with writing applications that didn't require serious architectural changes when new requirements were introduced. In 2010, I finally got fed up with the constant rewrites and began researching tools and techniques to help me with my problem. I quickly found TekPub, an e-learning site that was, at the time, owned and operated by Rob Conery. Through TekPub I began learning the SOLID principles and TDD. After banging my head against the wall for close to six months, I started to grasp what TDD was and how I could use those principles. Coupled with the SOLID principles, TDD helped me to write easy to understand code that was flexible enough to stand up to any requirements the business could throw at me. I eventually ended up at the same company where John was employed and worked with him and, as he said, the rest is history.

The original approach to TDD has caused some confusion over the years. The problem is that the principles and approaches just weren't structured enough. In 2006, Dan North wrote an article in Better Software magazine (https://www.stickyminds.com/better-software-magazine/behavior-modification). The purpose of the article was to clear up some of this confusion and help to reduce the pitfalls that developers fell into while learning the TDD process. This new approach to TDD is called Behavior Driven Development (BDD). BDD provides a structure for testing, and a means of communicating between business requirements and unit tests, that is almost seamless. 

It's difficult to start any journey without a goal in mind. There are a few tips and tricks that can be used to help get you started in TDD. The first is red, green, refactor.

We're professionals. We want to do a good job. We feel bad if someone finds fault with our code. If QA finds a bug, it makes us sad. If a user of our system encounters an error, we may cry. We should strive to deliver quality, error-free code and a fully functional, feature-rich application.

We're also lazy, but it's the good kind of lazy. We don't want to have to run the entire application just to validate that a simple function returns the proper value.

Of course, testing takes time. Writing unit tests takes time. Adhering to the red, green, refactor cycle of TDD does take time. But, how else do you check your work if not through tests?

Do you validate that the code you wrote works? How do you do this without tests? Do you manually run the application? How long does that take? Are there conditional scenarios that you need to account for within the application? Do you have to set up those scenarios while manually testing the application? Do you skip some and just trust that they work?

What about regression testing? What if you make a change a day, a week, or a month later? Do you have to manually regression-test the entire application? What if someone else makes a change? Do you trust that they were also as thorough in their testing, as I’m sure you are?

How much time would you save if your code were covered by a test suite that you could run at the click of a button?

By writing tests, you're effectively doubling the amount of code you're writing, right? Well, yes and no. Okay, in an extreme case, you might approach double the code. Again, in an extreme case.

In some instances, consulting companies have written unit tests into a contract with a line item and dollar amount attached. Inevitably, this allows the customer the chance to argue to have this line item removed, thus saving them money. This is absolutely the wrong approach. Testing will be done, period, whether manually by the developer running the application to validate her work, by a QA tester, or by an automated suite of tests. Testing is not a line item that can be negotiated or removed (yikes!).

You would never buy an automobile that didn’t pass quality control. Light bulbs must pass inspection. A client, customer, or company will never, ever, save money by foregoing testing. The question becomes, do you write the tests early, while the code is being authored, or manually, at a later date?

Testing can be difficult. This is especially true with an application that was not written with testability in mind. If you have static methods and implementations using concrete references scattered throughout your code, you will have difficulty adding tests at a later date.

I don't know how to test is really the only acceptable answer, assuming it is quickly followed by, but I'm willing to learn. We're developers. We're the experts in the room. We're paid to know the answers. It's scary to admit that we don't know something. It's even scarier to start something new. Rest assured, it will be OK. Once you get the hang of TDD, you’ll wonder how you managed before. You'll refer to those times as the dark ages, before the discovery of the wheel.

We already mentioned that we, as professionals, will not ship anything without first determining that it works. Throwing something over the wall to QA, to our users, or to the general public and hoping that it all works as expected just isn't how we do business. We will verify that our code and our applications work as expected. In the beginning, while the application is small and has little functionality, we can manually test everything we can think of. But, as the application grows in size and complexity, it just isn't feasible for developers or anyone else to manually test an entire application. It’s too time-consuming and costly to do this manually. We can save ourselves time and our clients and companies money by automating our testing. We can do so quite easily, from the beginning, through TDD.

As our application grows, so do our tests. Or shall we say, our test suite has grown, and by making our tests pass, our application has grown. As both have grown, we've covered the happy path (for example: 2 + 2 = 4) as well as potential failures (for example: 2 + banana = exception). If the method or function under test can accept an input parameter, there is a potential for failure. You can reduce the potential for unexpected behavior, bugs, and exceptions by writing code to guard against these scenarios. As you write tests to express potential failures, your production code will inherently become more robust and less prone to errors. If a bug does slip by and make it to QA, or even to a production environment, then it's easy enough to add a new test to cover the newly discovered defect.

The added benefit of approaching bugs in this fashion is that the same bug rarely crops up again at some later date, as the new tests guard against this. If the same bug does appear, you know that, while the same result has happened, the bug occurred in a new and different way. With the addition of another test to cover this new scenario, this will likely be the last time you see the same old bug.

With a comprehensive suite of tests, you can demonstrate some level of correctness. At some point, someone somewhere will ask you whether you are done. How will you show that you have added the desired functionality to an application?

Let's face it, we've all worked on legacy applications that we were scared to touch. Imagine if the class you were tasked with modifying were covered by a comprehensive set of unit tests. Picture how easy it would be to make a change and know that all was right with the world because all of the unit tests still passed.

Writing unit tests tends to push your code towards a decoupled design. Tightly coupled code quickly becomes burdensome to test, and so, to make one's life easier, a Test-Driven Developer will begin to decouple the code. Decoupled code is easier to swap in and out, which means that, instead of modifying a tangled knot of production code, often all that a developer needs to do to make the necessary changes is swap out a subcomponent with a new module of code. 

It may not feel like it at first (in fact, it definitely will not feel like it at first), but writing unit tests is an excellent way to speed up development. Traditionally, a developer receives requirements from the business, sits down, and begins shooting lightning from her fingertips, allowing the code to pour out until an executable application has been written. Before TDD, a developer would write code for a few minutes and then launch the application so that she could see if the code worked or not. When a mistake was found, the developer would fix it and launch the application once again to check whether the fix worked. Often, a developer would find that her fix had broken something else and would then have to chase down what she had broken and write another fix. The process described is likely one that you and every other developer in the world are familiar with. Imagine how much time you have lost fixing bugs that you found while doing developer testing. This does not even include the bugs found by QA or in production by the customer. 

Now, let's picture another scenario. After learning TDD, when we receive requirements from the business, we quickly convert those requirements directly into tests. As each test passes we know that, as per the requirements, our code does exactly what has been asked of it. We might discover some edge cases along the way and create tests to ensure the code has the correct behavior for each one. It would be rare to discover that a test is failing after having made it pass. But, when we do cause a test to fail, we can quickly fix it by using the undo command in our editor. This allows us to hardly even run the application until we are ready to submit our changes to QA and the business. Still, we try to verify that the application behaves as required before submitting, but now we don't do this manually, every few minutes. Instead, let your unit tests verify your code each time you save a file. 

Let's jump right in with the most misused and least understood test type. In Kent Beck's book, Test-Driven Development by Example, he defines a unit test as simply a test that runs in isolation from the other tests. All that means is that for a test to be a unit test, all that has to happen is that the test must not be affected by the side-effects of the other tests. Some common misconceptions are that a unit test must not hit the database, or that it must not use code outside the method or function being tested. These simply aren't true. We tend to draw the line in our testing at third-party interactions. Any time that your tests will be accessing code that is outside the application you are writing, you should abstract that interaction. We do this for maximum flexibility in the design of the test, not because it wouldn't be a unit test. It is the opinion of some that unit tests are the only tests that should ever be written. This is based on the original definition, and not on the common usage of the term. 

Tests that are directly affected by business requirements, such as those suggested in BDD, are generally referred to as acceptance tests. These tests are at the outermost limit of the application and exercise a large swathe of your code. To reduce the coupling of tests and production code, you could write this style of test almost exclusively. Our opinion is, if a result cannot be observed outside the application, then it is not valuable as a test. 

Integration tests are those that integrate with an external system. For instance, a test that interacts with a database would be considered an integration test. The external system doesn't have to be a third-party product; however, sometimes, the external system is just an imported library that was developed independently from the application you are working on but is still considered in-house software. Another example that most don't consider is interactions with the system or language framework. You could consider any test that uses the functions of C#'s DateTime object to be an integration test. 

These tests validate the entire configuration and usage of your application. Starting from the user interface, an end to end test will programmatically click a button or fill out a form. The UI will call into the business logic of the application, executing all the way down to the data source for the application. These tests serve the purpose of ensuring that all external systems are configured and operating correctly. 

The simplest way to get started and ensure that you have human-readable code is to structure your tests using Arrange, Act, and Assert.

While this book is not about business analysis or requirement generation, requirements will have a huge impact on your ability to effectively test-drive an application. We will be providing requirements for this book in a format that lends itself very well to high-quality tests. We will also cover some scenarios where the requirements are less than optimal, but for most of this book the requirements have been labored over to ensure a high-quality definition of the systems we are testing. 

As a <Role> 
I want <Request> 
So that <Reason> 

As a Conference Speaker 
I want to search for nearby conferences by open submission date 
So that I may plan the submission of my talks 

Given <Context> 
And Given <More Context> 
When <Action> 
Then <Result> 
And Then <More Results> 

Given I am a conference speaker 
And Given a search radius of 25 miles 
And Given an open submission start date 
And Given an open submission end date 
When I search for conferences 
Then I receive only conferences within 25 miles of my location 
And Then I receive only conferences that are open for submission within the specified date range 

As a conference speaker 
I want to search for nearby conferences 
So that I may plan the submission of my talks 
Given I am a conference speaker 
And Given search radius of five miles 
When I search for conferences 
Then I receive only conferences within five miles of my location 
Given I am a conference speaker 
And Given search radius of 10 miles 
When I search for conferences 
Then I receive only conferences within 10 miles of my location 
Given I am a conference speaker 
And Given search radius of 25 miles 
When I search for conferences 
Then I receive only conferences within 25 miles of my location 

As a conference speaker 
I want to search for conferences by open submission date 
So that I may plan the submission of my talks 
Given I am a conference speaker 
And Given open submission start and end dates 
When I search for conferences 
Then I receive only conferences that are open for submission within the specified date range 
Given I am a conference speaker 
And Given an open submission start date 
And Given an empty open submission end date 
When I search for conferences 
Then an INVALID_DATE_RANGE error occurs for open submission date 
Given I am a conference speaker 
And Given an empty open submission start date 
And Given an open submission end date 
When I search for conferences 
Then an INVALID_DATE_RANGE error occurs for open submission date 

Have you ever created a new MVC project in Visual Studio? Have you noticed the checkbox towards the bottom of the dialog box? Have you ever selected, Create Unit Test Project? The tests created with this Unit Test Project are largely of little use. They do little more than validate that the default MVC controllers return the proper type. This is perhaps one step beyond, ItExists. Let's look at the first set of tests created for us:

using System.Web.Mvc;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using SampleApplication.Controllers;

namespace SampleApplication.Tests.Controllers
{
  [TestClass]
  public class HomeControllerTest
  {
    [TestMethod]
    public void Index()
    {
      // Arrange
      HomeController controller = new HomeController();

      // Act
      ViewResult result = controller.Index() as ViewResult;

      // Assert
      Assert.IsNotNull(result);
    }

    [TestMethod]
    public void About()
    {
      // Arrange
      HomeController controller = new HomeController();

      // Act
      ViewResult result = controller.About() as ViewResult;

      // Assert
      Assert.AreEqual("Your application…", result.ViewBag.Message);
    }

    [TestMethod]
    public void Contact()
    {
      // Arrange
      HomeController controller = new HomeController();

      // Act
      ViewResult result = controller.Contact() as ViewResult;

      // Assert
      Assert.IsNotNull(result);
    }
  }
}

Here, we can see the basics of a test class, and the test cases contained within. Out of the box, Visual Studio ships with MSTest, which is what we can see here. The test class must be decorated with the [TestClass] attribute. Individual tests must likewise also be decorated with the [TestMethod] attribute. This allows the test runner to determine which tests to execute. We'll cover these attributes and more in future chapters. Other testing frameworks use similar approaches that we'll discuss later, as well.

For now, we can see that the HomeController is being tested. Each of the public methods has a single test, for which you may want to create additional tests and/or extract tests to separate files in the future. Later we'll be covering options and best practices to help you arrange your files in a much more manageable fashion. All of this should be part of your refactor step in your red, green, refactor cycle.

[TestMethod]
public void ItTakesOptionalName()
{
  // Arrange
  HomeController controller = new HomeController();

  // Act
  ViewResult result = controller.About("") as ViewResult;

  // Assert
  Assert.AreEqual("Your application description page.", result.ViewBag.Message);
}

public ActionResult About(string name = default(string))
{
  ViewBag.Message = "Your application description page.";
  return View();
}    

[TestMethod]
public void ItReturnsNameInMessage()
{
  // Arrange
  HomeController controller = new HomeController();

  // Act
  ViewResult result = controller.About("Fred") as ViewResult;

  // Assert
  Assert.AreEqual("Your application description page.Fred", result.ViewBag.Message); 
}

public ActionResult About(string name = default(string))
{
  ViewBag.Message = $"Your application description page.{name}";
  return View();
}

To get the ball rolling in JavaScript, we are going to write a Simple Calculator class. Our calculator only has the requirement to add or subtract a single set of numbers. Much of the code you write in TDD will start very simply, just like this example:

import { expect } from 'chai'

class SimpleCalc {
  add(a, b) {
    return a + b;
  }

  subtract(a, b) {
    return a - b;
  }
}

describe('Simple Calculator', () => {
  "use strict";

  it('exists', () => {
    // arrange
    // act
    // assert
    expect(SimpleCalc).to.exist;
  });

  describe('add function', () => {
    it('exists', () => {
      // arrange
      let calc;

      // act
      calc = new SimpleCalc();

      // assert
      expect(calc.add).to.exist;
    });

    it('adds two numbers', () => {
      // arrange
      let calc = new SimpleCalc();

      // act
      let result = calc.add(1, 2);

      // assert
      expect(result).to.equal(3);
    });
  });

  describe('subtract function', () => {
    it('exists', () => {
      // arrange
      let calc;

      // act
      calc = new SimpleCalc();

      // assert
      expect(calc.subtract).to.exist;
    });

    it('subtracts two numbers', () => {
      // arrange
      let calc = new SimpleCalc();

      // act
      let result = calc.subtract(3, 2);

      // assert
      expect(result).to.equal(1);
    });
  });
});

If the preceding code doesn't make sense right now, don't worry; this is only intended to be a quick example of some working test code. The testing framework used here is Mocha, and the assertion library used is chai. In the JavaScript community, most testing frameworks are built with BDD in mind. Each described in the code sample above represents a scenario or a higher-level requirements abstraction; whereas, each it represents a specific test. Within the tests, the only required element is the expect, without which the test will not deliver a valuable result.

Continuing this example, say that we receive a requirement that the add and subtract methods must be allowed to chain. How would we tackle that requirement? There are many ways, but in this case, I think I would like to do a quick redesign and then add some new tests. First, we will do the redesign, again driven by tests.

By placingonly on a describe or a test, we can isolate that describe/test. In this case, we want to isolate our add tests and begin making our change here:

it.only('adds two numbers', () => {
  // arrange
  let calc = new SimpleCalc(1);

  // act
  let result = calc.add(2).result;

  // assert
  expect(result).to.equal(3);
});

Previously, we have changed the test to use a constructor that takes a number. We have also reduced the number of parameters of the add function to a single parameter. Lastly, we have added a result value that must be used to evaluate the result of adding.

The test will fail because it does not use the same interface as the class, so now we must make a change to the class:

class SimpleCalc {
  constructor(value) {
    this._startingPoint = value || 0;
  }

  add(value) {
    return new SimpleCalc(this._startingPoint + value);
  }
  ... 
  get result() {
    return this._startingPoint;
  }
}

This change should cause our test to pass. Now, it's time to make a similar change for the subtract method. First, remove the only that was placed in the previous example:

it('subtracts two numbers', () => {
  // arrange
  let calc = new SimpleCalc(3);

  // act
  let result = calc.subtract(2).result;

  // assert
  expect(result).to.equal(1);
});

Now for the appropriate change in the class:

subtract(value) {
  return new SimpleCalc(this._startingPoint – value);
}

Out tests now pass again. The next thing we should do is create a test that verifies everything works together. We will leave this test up to you as an exercise, should you want to attempt it.