The Unit

“Do one thing, and do it well” is the mantra when you are building an application with unit tests. Too often we write functions that try to do too many things. Not only is this very inefficient, as it does not lead to reuse, but it also makes these functions very difficult to test.

Consider this simple function: given a customer’s address, the function determines the cost to ship a product to that customer from the nearest distribution center.

Let’s break this function down a bit. The first thing that happens is that our function uses the address to find the nearest distribution center. Using that distribution center address, the function then determines the distance between the center and the customer’s address. Lastly, using that distance, the function calculates the shipping cost to move the package from point A to point B. So even though we have a single function, the function is performing three separate actions:

1. Look up distribution center nearest to given address.
2. Calculate a distance between two addresses.
3. Evaluate shipping cost for a given distance.

Going back to the idea of “doing one thing, and doing it well,” it is pretty obvious that we could better accomplish our address lookup action by combining three separate functions. When our action is split up, we get a function that allows us to find the nearest distribution center to any given address, a function that calculates the distance between two given addresses, and a function that returns the cost of shipping a product any given distance.

Test-Driven Development

When most of us first approached unit testing, we probably wrote up some functionality that met a business goal (such as our shipping example) and then worked to refactor it into smaller, reusable, testable bits. At that point, we would consider the tests we’d want to write. Test-driven development (TDD) turns that idea upside down by putting the tests first, before any functional code is even written.

But if we write tests for functions we haven’t created, won’t they all fail? Exactly! TDD sets out to describe how a system should work when written properly, and creates a path for us to create that system.

For our shipping example, TDD would write three tests, one for each of the three functions required to perform this business function. The developer’s job is to turn those failing tests into passing tests. First, we write a function that properly looks up the location of the nearest distribution center, and we have one passing test. We then move on to measuring distance and calculating shipping, and finish with three functions that make their associate test pass.

With this done, not only have we built the functionality required for our application to look up shipping cost, but we have complete test coverage for these functions.

A Test-Driven Example

At its core, unit testing is extremely simple. The basic idea is to call the function being tested, passing it preset values and describing what the result should be. Let’s look at how we’d do this for our function that calculates the shipping cost for a given distance:

function calculateShipping(distance) {
  switch (distance) {
    case (distance < 25):
      shipping = 4;
      break;
    case (distance < 100):
      shipping = 5;
      break;
    case (distance < 1000):
      shipping = 6;
      break;
    case (distance >= 1000):
      shipping = 7;
      break;
    }
    return shipping;
  }

QUnit.test('Calculate Shipping', function(assert) {
  assert.equal(calculateShipping(24), 4, "24 Miles");
  assert.equal(calculateShipping(99), 5, "99 Miles");
  assert.equal(calculateShipping(999), 6, "999 Miles");
  assert.equal(calculateShipping(1000), 7, "1000 Miles");
};

QUnit has several operators for testing assertions, including ok() for testing Boolean values or deepEqual() for comparing complex objects. In this case, we are using the equal() function to compare the value returned by calculateShipping() with the expected result. As long as calculateShipping(24) returns a value of 4 (which it will here), our test will pass. The third value, 24 Miles, is used to label the pass/fail statement in the test output.

With these tests (and others) in place, we have a single suite to run that will assert whether or not our system is working. If someone were to change the name of the calculateShipping() function or modify the shipping prices, this test would return failures, and we could fix the problem before offending code was pushed to production.

QUnit is capable of doing much more than the preceding example. For instance, it is capable of performing tests on both synchronous and asynchronous functions. QUnit can also interact with the web page that the tests are loaded on (remember, this is all just JavaScript). So if your tests include values being returned when a mouse is clicked or a key is pressed, QUnit has you covered there too.

How Much Coverage Is Enough?

Determining proper test coverage can be a very difficult balancing act. If you aren’t running test-driven development (where nothing is written without tests), it will be important to determine how much coverage is enough coverage. Test everything, and your development process can get bogged down. Don’t test enough, and you risk regressions slipping through.