In test-driven development , we write tests before writing code. This way, we can observe that a test fails, add new code, and then see that the test passes, verifying that our change has the intended effect.

Let's start by testing the child selector that we used in Chapter 2 to add a horizontal class to all <li> elements that are children of <ul id="selected-plays">:

test('Child Selector', function() {
  expect(1);
  var topLis = $('#selected-plays > li.horizontal');
  equal(topLis.length, 3, 'Top LIs have horizontal class');
});

Here, we have actually introduced two tests. We begin with the expect() test, which instructs QUnit how many tests we expect to run in this set. Then, because we are testing our ability to select elements on the page, we use the equal() test to compare the number of top-level <li> elements against the number 3. If the two are equal, the test passes:

Of course, the test fails because we have not yet written the code to add the horizontal class. It is simple to add that code, though. We do so in the main script file for the page, which we named B.js:

$(document).ready(function() {
  $('#selected-plays > li').addClass('horizontal');
});

When we run the test now, it passes:

Now the Selecting: Child Selector test shows no failing tests and one passing test out of a total of one test. We can add a couple of attribute selector tests as well:

module('Selecting', {
  setup: function() {
    this.topLis = $('#selected-plays > li.horizontal');
  }
});

test('Child Selector', function() {
  expect(1);
  equal(this.topLis.length, 3,
    'Top LIs have horizontal class');
});

test('Attribute Selectors', function() {
  expect(2);
  ok(this.topLis.find('.mailto').length == 1, 'a.mailto');
  equal(this.topLis.find('.pdflink').length, 1, 'a.pdflink');
});

Here we have introduced another type of test: ok(). This one takes two arguments: an expression that should evaluate to a "truthy" value, and a description. Also, note that we have moved the local topLis variable out of the Child Selector test and into the module's setup() callback function. The module() takes an optional second argument, which is a map that can include a setup() and a teardown() function. Within these functions, we can use the this keyword to assign variables once for all of a module's tests.

Again, the new tests will fail without the corresponding working code, so let's include that in the script as follows:

$(document).ready(function() {
  $('#selected-plays > li').addClass('horizontal');
  $('a[href^="mailto:"]').addClass('mailto');
  $('a[href$=".pdf"]').addClass('pdflink');
});

If we expand the newly passing test set, we can see the difference in output between the ok() and equal() tests, as shown in the following screenshot:

In addition to indicating that both of the tests have passed with the green color, the equal() test details the expected result. As it provides more information, the equal() test is typically preferred over the ok() test.

asyncTest('JSON', function() {
  $.getJSON('B.json', function(json, textStatus) {
    // add tests here
  }).always(function() {
    start();
  });
});

asyncTest('JSON', function() {
  expect(2);
  var backbite = {
    "term": "BACKBITE",
    "part": "v.t.",
    "definition": "To speak of a man as you find him when he can't find you."
  };

  $.getJSON('B.json', function(json, textStatus) {
    equal(textStatus, 'success', 'Request successful');
    deepEqual(json[1], backbite,
      'result array matches "backbite" map');
  }).always(function() {
    start();
  });
});