Test driven development (TDD) has gained a lot of prominence in the last few years. The concept was first proposed as part of the extreme programming methodology. The idea is to have short repetitive development cycles where the focus is on writing the test cases first. The cycle looks like the following:

These steps are repeated for any new code you add. This is an elegant strategy that works really well for agile methodology. TDD will be successful only if the testable units of code are small and confirms only to the test case.

A very common problem while trying to follow TDD is vocabulary and the definition of correctness. BDD tries to introduce a ubiquitous language while writing the test cases when you are following TDD. This language makes sure that both the business and the engineering are talking about the same thing.

We will use Jasmine as the primary BDD framework and explore various testing strategies.

When you unzip this package, you will see the following directory structure:

The lib directory contains the JavaScript files that you need in your project to start writing Jasmine test cases. If you open SpecRunner.html, you will find the following JavaScript files included in it:

    <script src="lib/jasmine-2.3.4/jasmine.js"></script> 
    <script src="lib/jasmine-2.3.4/jasmine-html.js"></script> 
    <script src="lib/jasmine-2.3.4/boot.js"></script>     
 
    <!-- include source files here... -->    
    <script src="src/Player.js"></script>    
    <script src="src/Song.js"></script>     
    <!-- include spec files here... -->    
    <script src="spec/SpecHelper.js"></script>    
    <script src="spec/PlayerSpec.js"></script> 

The first three are Jasmine's own framework files. The next section includes the source files we want to test and the actual test specifications.

Let's experiment with Jasmine via a very ordinary example. Create a bigfatjavascriptcode.js file and place it in the src/ directory. The function we will test is as follows:

    function capitalizeName(name){ 
      return name.toUpperCase(); 
    } 

This is a simple function that does one single thing. It receives a string and returns a capitalized string. We will test various scenarios around this function. This is the unit of code, which we discussed earlier.

Next, create the test specifications. Create one JavaScript file, test.spec.js, and place it in the spec/ directory. You will need to add the following two lines into your SpecRunner.html: The file should contain the following:

    <script src="src/bigfatjavascriptcode.js"></script>     
    <script src="spec/test.spec.js"></script>    

The order of this inclusion does not matter. When we run SpecRunner.html, you will see something like the following image:

This is the Jasmine report that shows details about the number of tests that were executed and the count of failures and successes. Now, let's make the test case fail. We want to test a case where an undefined variable is passed to the function. Let's add one more test case, as follows:

    it("can handle undefined", function() { 
        var str= undefined; 
        expect(capitalizeName(str)).toEqual(undefined); 
    }); 

Now, when you run SpecRunner, you will see the following result:

As you can see, the failure is displayed for this test case in a detailed error stack. Now, we will go about fixing this. In your original JS code, handle undefined as follows:

    function capitalizeName(name){ 
      if(name){ 
        return name.toUpperCase(); 
      }   
    } 

With this change, your test case will pass, and you will see the following result in the Jasmine report:

This is very similar to what a test-driven development would look like. You write test cases and then fill the necessary code to confirm to the specifications and rerun the test suite. Let's understand the structure of the Jasmine tests.

Our test specification looks like the following piece of code:

    describe("TestStringUtilities", function() { 
          it("converts to capital", function() { 
              var str = "albert"; 
              expect(capitalizeName(str)).toEqual("ALBERT"); 
          }); 
          it("can handle undefined", function() { 
              var str= undefined; 
              expect(capitalizeName(str)).toEqual(undefined); 
          }); 
    }); 

The describe("TestStringUtilities" is what a test suite is. The name of the test suite should describe the unit-of-code we are testing; this can be a function or a group of related functionality. Inside the specs, you will call the global Jasmine function,it, to which you will pass the title of the spec and the function that validates the condition of the testcase This function is the actual test case. You can catch one or more assertions or the general expectations using the expect function. When all expectations are true, your spec is passed. You can write any valid JavaScript code inside describe and it functions. The values you verify as part of the expectations are matched using a matcher. In our example, toEqual is the matcher that matches two values for equality. Jasmine contains a rich set of matches to suit most of the common use cases. Some common matchers supported by Jasmine are as follows:

An interesting feature of Jasmine is the spies. When you are writing a large system, it is not possible to make sure that all systems are always available and correct. At the same time, you don't want your unit tests to fail due to a dependency that may be broken or unavailable. To simulate a situation where all dependencies are available for a unit of code we want to test, we will mock this dependency to always give the response we expect. Mocking is an important aspect of testing, and most testing frameworks provide support for mocking. Jasmine allows mocking using a feature called a Spy. Jasmine spies essentially stubs the functions we may not have ready at the time of writing the test case, but as part of the functionality, we will need to track that we are executing those dependencies and not ignoring them. Consider the following example:

    describe("mocking configurator", function() { 
      var cofigurator = null; 
      var responseJSON = {}; 
 
      beforeEach(function() { 
        configurator = { 
          submitPOSTRequest: function(payload) { 
            //This is a mock service that will eventually be replaced  
            //by a real service 
            console.log(payload); 
            return {"status": "200"}; 
          } 
        }; 
        spyOn(configurator, 'submitPOSTRequest').and.returnValue
         ({"status": "200"}); 
       configurator.submitPOSTRequest({ 
          "port":"8000", 
          "client-encoding":"UTF-8" 
        }); 
      }); 
 
      it("the spy was called", function() { 
        expect(configurator.submitPOSTRequest).toHaveBeenCalled(); 
      }); 
 
      it("the arguments of the spy's call are tracked", function() { 
        expect(configurator.submitPOSTRequest).toHaveBeenCalledWith(
          {"port":"8000", "client-encoding":"UTF-8"}); 
      }); 
    }); 

In this example, while we are writing this test case, we either don't have the real implementation of the dependency, configurator.submitPOSTRequest(), or someone is fixing this particular dependency; in any case, we don't have it available. For our test to work, we will need to mock it. Jasmine spies allow us to replace a function with its mock and allows us to track its execution.

In this case, we will need to ensure that we called the dependency. When the actual dependency is ready, we will revisit this test case to make sure it fits the specifications; however, at this time, all we need to ensure that the dependency is called. Jasmine function tohaveBeenCalled() lets us track the execution of a function that may be a mock. We can use toHaveBeenCalledWith(), which allows us to determine if the stub function was called with correct parameters. There are several other interesting scenarios you can create using Jasmine spies. The scope of this chapter won't permit us to cover them all, but I would encourage you to discover those areas on your own.

Though Jasmine is the most prominent JavaScript testing framework, mocha and chai are gaining prominence in the Node.js environment:

We won't discuss these frameworks in this book; however, experience on Jasmine will be handy if you want to experiment with these frameworks.