Chapter 8. Unit testing

This chapter covers

• An introduction to unit testing
• Using JavaScript testing frameworks
• Unit testing MV* objects
• An introduction to behavior-driven development unit testing

When you create software, regardless of the platform or language used, you want to do your best to ensure that you’re delivering a quality product. In this book, you’ve looked at various ways to create a maintainable, robust SPA, such as dividing your code into modules and using the power of MV* frameworks. Another vital facet of SPA programming is testing. Testing what you write is just as important to the delivery of the end product as the code itself. Putting your code through the paces does a lot more than uncover bugs. When you see that your code does what you expect it to and can handle failures gracefully, this helps you write better code and improves your confidence in the application.

Although an application can be subjected to a variety of tests, this chapter focuses specifically on unit testing. The upcoming sections cover what a unit test is, how to create code that’s more conducive to unit testing, and what some of the benefits are. Even though certain aspects of unit testing are subjective, we can zero in on some of its most common features.

We’ll frame our discussions around unit testing applications built using MV* frameworks and modular code. After we’ve covered some basic unit-testing concepts, we’ll talk about writing unit tests for an SPA using a framework called QUnit. QUnit is powerful but still easy to use and doesn’t have a steep learning curve.

The project in this chapter keeps things extremely simple. This will help you stay focused on the unit-testing aspect of your project’s development. You’ll create the project by using Backbone.js, Knockout, and AngularJS to illustrate testing across a variety of MV* framework styles.

8.1. Understanding the project

For this project, you’ll create a basic tip calculator. I’ll introduce various parts of this project when you begin writing unit tests later in this chapter. Before you begin, let’s take a moment to see what the final product looks like (see figure 8.1).

Figure 8.1. Our sample project calculates the amount of the tip and the total amount to be paid. It also rates the tip given.

Keep this image in your mind as you go through each section. As usual, the entire code (this time with tests) is available for download.

8.2. What is a unit test?

In a broad sense, a unit test is a test performed on the smallest testable part of an application. This type of test is a low-level test performed during development by the developer. Additionally, whether the test subject is an MV* object or a general module you’ve created, unit tests typically make assertions about how code behaves.

A unit test can also be characterized by its relationship to other types of tests. A pyramid structure is often used to describe different test types in terms of measurements such as scope, time, and level of effort. Because unit tests are narrow in focus and scope, are quick to run and easy to maintain, and provide fast feedback for results, they’re at the pyramid’s base (see figure 8.2).

Figure 8.2. A unit test is a low-level, focused test created during development that’s quick to execute and offers the least lag in getting test results.

Now that you know what unit tests are, let’s look at why you should care about creating them.

8.2.1. Benefits of unit testing

Unit testing is about a lot more than finding bugs in your code. In reality, you’ll likely find more bugs in other, more high-level tests. Unit testing is about designing better software. This list highlights some of the benefits of unit testing:

• Can lead to better software designs —Creating code that’s easily unit tested helps reinforce the idea that software components should be loosely coupled with highly specialized parts. This can lead to a better-designed application as a whole.
• Helps detect issues early on —A passing unit test, which is well written and useful, is proof that the code you write is working as expected. The sooner you can detect code bugs, the easier and less costly it is to correct the problem.
• Gives you more confidence to make changes —Sometimes you might be hesitant to make changes because you don’t want to break something that’s already working. Unit tests can help bolster your confidence in this area. A good unit test is one that’s repeatable with consistent results. As you refactor, the same unit tests that were successful before the changes should still be successful after the changes.
• Provide great examples of how your code works —Although you’ll still want to document your application, unit tests provide a convenient way for others to see how your code should work. Well-written unit tests illustrate proper usage for other developers who might want a quick dive into the code. They can also serve as an introduction to the code base for new team members.

Having highlighted some of the benefits, let’s talk about how to get the most out of the tests you write.

8.2.2. Creating better unit tests

Although there’s no official rulebook on unit testing, you can follow general best practices to make your unit tests be good unit tests.

Focus each test on a specific business-related concept

Ideally, each unit test should focus on specific concepts in your code. If the scope of the unit test is too broad or focuses on things beyond specific business requirements, you’ll have a hard time pinpointing specific areas in your code that aren’t working as designed.

For example, don’t try to initiate a unit test through automated user actions, such as the filling out of a form or the clicking of a button. Even though processes in an SPA are often initiated by user-driven events, UI-level testing is much broader in scope than unit testing, because it often generates multiple activities at once at various levels in the application. It’s far better to test the lower-level parts of your code.

You also may be tempted to test that third-party software works as advertised if you’re using it in your own code. But the focus of your unit test should be only on logic you’ve written. If the third-party software has a bug, it’s incidental to your unit test and should be considered out of scope for a unit test.

Let’s consider for a moment our tip calculator project as an example. Figure 8.3 provides a high-level picture of what you might want to consider in scope when unit testing this application.

Figure 8.3. Focus unit tests on the lowest level of the application’s logic.

Another way to create more easily testable code is by avoiding ambiguous or nonspecific APIs. These types of APIs generally aren’t well designed. This will become evident when you try to test them.

Avoid creating APIs that are ambiguous or too general

Poorly written APIs are not only bad for the application but also extremely difficult to unit test. If you can’t easily test the individual parts of your business logic, this is a sign that you should consider refactoring your code.

For example, the tip calculator application displays several values at once when the Calculate button is clicked. You should be able to test the logic behind each calculation independently. Because the application is so simple, it would be easy enough to calculate everything in one function (see figure 8.4).

Figure 8.4. In this design, all the logic is hidden behind this one vague API.

Now let’s refactor things a bit and give each area of concern in the business logic its own function in the API. Figure 8.5 separates the tasks that were formerly lumped together.

Figure 8.5. Smaller, specialized functions are a better fit for unit testing.

When developers create APIs that are easy to unit test, one pleasant side effect is that the code is often more readable, more specialized, and more easily maintained.

In addition to being vigilant with your code, you also can structure the unit tests themselves to make them better.

No testing order should be required

You’ll often find yourself writing many unit tests for a feature. Most testing tools allow you to then divide tests into groups (or suites). You should avoid including tests that will work only if they’re in a particular order within the test suite. The position of a unit test within your suite shouldn’t matter. If you’ve created a suite of good unit tests for your SPA, you should be able to run them in any order and achieve the same results consistently. In your tip calculator tests, for example, testing the calculation for the tip amount should produce the same results whether it’s run first, last, or somewhere in the middle of all the other tests.

In the case of the tip calculator, your test suite might include the tip amount calculation first, the new bill total calculation second, and the tip rating third. But if for some reason you decide to rearrange this order, the results of each test should still be the same as they were with the previous test order.

Unit tests should be self-reliant

Good unit tests should be repeatable with consistent results. The only real way to ensure this is to have tests that can be contextually isolated and don’t rely on outside dependencies in order to work properly.

For starters, unit tests should be repeatable even when run in an environment other than the one they were originally written in. For example, your tip calculator unit tests should yield the same results when run in your local development environment as they would if the tests were automated on a dedicated machine.

Second, your unit tests shouldn’t rely on any external systems or even other tests. You’re not using server-side code in this simple project, but let’s imagine you were. Suppose that your tip ratings came from a database instead of being hardcoded in your application logic. If you were to create a unit test to make sure that a particular tip would yield the correct rating, you shouldn’t make a call to the server every time your test runs. Remember that a good unit test needs to be fast and reliable, with consistent results. External systems affect tests because call responses vary, which can make the execution time of your tests unpredictable. Relying on external systems also makes your tests vulnerable to outside issues, such as network problems or a server being down. Additionally, any changes made in a remote system, such as a data change or configuration change, could lead to inconsistent results. To avoid reliance on external systems, you can use mocks instead. Mocks are objects with preprogrammed expectations that can take the place of real ones in your unit tests. For example, you can use mocks as stand-ins for your live web service calls. They can behave as system calls but with the response you need for your tests.

Finally, if additional functions are required for the primary function you’re testing to work properly, you can isolate your test function by temporarily replacing any other functions with stubs. Stubs are temporary replacements with predetermined behavior. They allow you to focus a unit test on your primary function without worrying about the behavior of other parts of your code.

The focus of each test should be easily understood

A good unit test can also be measured by how easily its objective is understood just by looking at the test title and comments. People tend to forget things over time, so it’s immensely helpful to be able to glance at a unit test and know why it exists.

Here’s an example from this chapter’s project. For the traditional unit test on our tip amount calculation, table 8.1 shows the title of the suite and the test, as well as its comments. From this information, the purpose of the test should be clear, whether the person looking at the test is a business analyst, a QA tester, another developer, or a business owner.

Table 8.1. Example of clear, easily understood titles and comments for a unit test

Suite title	Test title	Test comments
Tip Calculations	Calculate Tip Amount	15% tip for $10 should yield $1.50

Having discussed various aspects of unit testing, it’s time to see some unit tests in action. You’ll build a good foundation by starting with some traditional unit testing before moving on to testing for behavior-driven development.

8.3. Traditional unit testing

You can approach unit testing in various ways. The traditional method is to write your code first and then create unit tests around what you’ve written (see figure 8.6). This approach is also simple and easy to follow.

Figure 8.6. With traditional unit testing, tests are written after the code has been created.

The traditional approach is just one style of designing unit tests. Some people prefer this approach because they like tackling the code first and then creating tests to make sure the design is solid. Because the goal of unit testing is to create better software, others argue that traditional unit tests are too removed from the design process. Just for comparison, let’s contrast this with unit tests written for test-driven development (TDD).

The tests you create, TDD or otherwise, define the behavior of what you’re creating. With TDD, you’re associating the unit test with the design process even more by putting it up front. Because you’re relying on a well-written test to help in the design of the code, you’re forced to have a deep understanding of the requirements up front.

The test will fail at first, because you haven’t written code yet. The next step is to create the minimum amount of code needed to make the test pass. This develops a baseline for the new feature or enhancement. Next, you keep refactoring the code so it goes from minimally acceptable to well-designed, production-ready code. Every time you refactor, all tests are run again. This keeps you confident that with every improvement you haven’t inadvertently broken anything or created code that no longer satisfies the point of the test. Figure 8.7 illustrates this cyclical process.

Figure 8.7. In test-driven development, tests are written before the code is created.

Because traditional unit testing is straightforward, let’s use this approach to get your feet wet with creating some basic unit tests for this chapter’s project.

To unit test your SPA, you’ll need to choose a JavaScript testing framework. There are many to choose from, and we’ll talk about some of the other options in a later section. You’ll begin, though, with one of the oldest and easiest to use frameworks, called QUnit.

8.3.1. Getting started with QUnit

The first thing you need to do is download the software. QUnit can be found at http://qunitjs.com. You’ll need both the JavaScript file and the CSS file. Next, you need to get your testing environment ready. Your first task is to create a directory structure within your project to house your test scripts.

Creating a test directory

As with the project itself, your directory structure for your test scripts is a matter of personal taste. One common approach is to set up a directory structure similar to that of the application. This test directory is usually separate from the application’s source code.

To get exposure to testing using various MV* frameworks, I’ve created this chapter’s project using Backbone.js, Knockout, and AngularJS. To give you an idea of what a test directory might look like, figure 8.8 demonstrates the directory structure of the Backbone.js version of the application. You’ll follow the same approach for the Knockout and AngularJS versions. This same approach can also be applied to whichever type of MV* framework you ultimately decide to use in your own project.

Figure 8.8. The test directory will have a similar structure but is usually kept separate from the application’s source.

With your directory set up, you need a place to display the output of your tests. You’ll need to create a new HTML page for this.

Defining a test results page

After you have a test directory, QUnit also needs an HTML page to display the results of your unit tests. For this demo, I’ve created a file called test.html. To view the page, you’ll go directly to its URL in the browser. You don’t want a link to any test pages in the application.

Listing 8.1 shows the structure of your test results page. In real-world solutions, you’ll most likely use a build tool to gather the required includes. Because we’re not covering the build process until the next chapter, you’ll include any files needed directly in the HTML for the test results page with your AngularJS version. You’ll include references to both the test scripts and the source files for the application in your test results page.

Listing 8.1. test.html—AngularJS version

The Knockout and Backbone.js versions use AMD-style modules and RequireJS. When using RequireJS, your HTML page will be nearly identical except that the other SCRIPT tags are replaced with a single SCRIPT tag referencing RequireJS (see listing 8.2). Its data-main attribute defines the location of the main application file. This file (main-test.js) contains references to the locations of your frameworks, application source files, and test scripts.

Listing 8.2. test.html—Knockout and Backbone.js version

Also, when using AMD-style modules, unit tests are defined like any other module, using define(). The suite itself is kicked off inside require(), just like the project. Listing 8.3 shows what the require() definition looks like for our Knockout version. The Backbone.js version is similar and follows the same approach. If you need to see the complete file, you can find it in the downloadable source code for this chapter.

In this case, you’ve created custom addTests() APIs for each module. These do nothing more than execute the QUnit test functions, which add the tests to the list of tests that the framework will run. You’ll see an example of these in a moment.

Listing 8.3. main-test.js—Knockout version using AMD modules and RequireJS

Note

QUnit’s autoStart needs to be set to false in the RequireJS configuration file, and its load() and start() functions manually executed, after your tests have been added.

With your environment all set up, you can finally start writing some test scripts. In the next section, you’ll learn what QUnit asserts are and how to use them to create a unit test.

8.3.2. Creating your first unit tests

All three versions of your project perform two calculations: one for the tip amount and the other for a new bill total. In addition, logic in each version gives a rating such as “Standard” or “Great!” to the tip percent entered. I’ve tried to make each version of the project as similar as possible, though some differences exist because of the differences in each framework. For example, in the AngularJS version, your business logic is in a service component of the AngularJS module. In the Knockout version, the business logic resides in an ancillary AMD module. Last, for your Backbone.js version, your business logic can be found in the model used by the view for the entry form.

With that said, let’s get started. To create your first unit test, you’ll need to understand assertions in QUnit.

Making an assertion

The basic idea behind the unit tests you’ll create is that you’re going to assert that something is true. When a QUnit test is executed, each assertion is evaluated. QUnit either passes or fails each unit test by verifying its assertion. The assertion you’re making can be anything you want it to be. For example, it could be as simple as verifying that a particular object exists or it might be verifying the result of an operation.

QUnit provides many types of assertions. The full list can be found at http://api.qunitjs.com/category/assert. For these unit tests, you’re using only one type of assertion:

strictEqual()—This assertion compares the first and second parameters for equality. Its third parameter is for a comment. It uses the strict equality operator ===.

Let’s create your first test by using the calculations from the Knockout version of the application. In this version, your business logic is in a standard AMD module. No special setup is needed. For the Backbone.js version, your calculation logic is in the model, and in the AngularJS version, it’s in a service. We’ll discuss testing MV* objects a little later.

Writing a unit test

Your first unit test will test the output of your tip amount and new bill total calculations. To give the test script some context, the following listing shows what that code looks like. Remember that the entire source for the project is available for download should you need it.

Listing 8.4. Logic to calculate the tip amount and new bill total

Now let’s write the unit test. The syntax of a QUnit test is simple. You call a test() function, giving the test a title and a function containing your assertions, as shown in the following listing.

Listing 8.5. Unit test to verify the roundTipPercent() function

When the test runs, you should see the test report displayed in your test’s HTML page you set up earlier. By default, each test doesn’t show the test comments. In figure 8.9, I’ve clicked the test title to display the passing assertions for this test as well.

Figure 8.9. QUnit test report after your first unit test is run

If one of your tests failed, the test report would look similar to figure 8.10. QUnit displays what was expected, the result, the difference between those two, and the stack trace leading to the line that was executed.

Figure 8.10. QUnit test report with a failed test

Creating a unit test is that simple. Now let’s finish writing tests for the rest of the utility. Before we do that, though, let’s group these tests under a single heading.

Grouping tests

Another nice feature of QUnit is that it lets you group tests by using its module() method. In this case, you’re going to group all the calculation utility tests under a single heading. This will help you later, when you add tests for other areas of the application. In QUnit, grouping your tests into a module is a simple one-liner:

module("Tip Calculator Util Tests");

The following listing shows the complete set of tests for your tip calculator’s utility module.

Listing 8.6. Utility tests grouped within a module

Figure 8.11 shows what your test report looks like now, with all the tests for this one test module. Keep in mind that each test initially displays collapsed but can be expanded, as shown previously, to see the comments.

Figure 8.11. QUnit test report shows tests grouped together as a test module.

Business-related code inside an MV* object can also be tested similarly. The only trick is the amount of setup you might need to do.

8.3.3. Testing code built with MV* objects

As far as the mechanics of crafting the unit test go, unfortunately no magic formula fits everything. Because each framework/library is different, and each object type within a framework/library has a different purpose, the amount of setup needed for the test to run varies. Setup is usually minimal, though.

You also can follow a few simple rules of thumb when unit testing MV* objects:

• Don’t share objects between tests —Avoid trying to share MV* objects among tests. Our brains as developers are hardwired to find ways to reuse objects and avoid duplicate code. But in the case of unit testing, don’t share.
• Keep tests DRY —As you would with your production code, avoid repeating the same code in every test. Factor out repeated code into separate functions. Many testing frameworks have a type of setup process as well for any code that needs to run before each test.
• Consult the MV* documentation for any special instructions around testing —For frameworks such as Backbone.js or Knockout, you merely create new instances of any MV* objects you need to use. For some frameworks, such as AngularJS, you’ll need to take care of some specific setup tasks to be able to test components correctly. You’ll see this in a moment when you test the AngularJS version of your tip calculator SPA.

With these points in mind, let’s try unit testing a few types of MV* objects. I won’t cover the gamut of MV* objects here. The source for each version of the project, along with the entire suite of tests for each, is available for download. You will, however, take on a couple to get the idea.

Let’s start with the Backbone.js business logic of your tip calculator. You’ll test the same type of calculations that were in the utility module of the Knockout version of the project. The time, the code for this logic is in a Backbone.js model, as shown in the following listing.

Listing 8.7. Unit test for a Backbone.js model’s business logic

In the listing, notice the beforeEach() function. QUnit has an optional beforeEach() function for any pretest setup and an optional afterEach() function for teardown/cleanup work. With the new instance created in the beforeEach() function, you can now test the model’s logic.

Continue with your model and create the tests for the rating logic, as shown in the following listing.

Listing 8.8. Rating logic for the Backbone.js model

Because you can group things into QUnit modules, you have one for the model’s validation logic and the other for the calculations. Figure 8.12 shows what the test suite looks like at this point.

Figure 8.12. QUnit testing against a Backbone.js model

Now let’s look at unit testing an AngularJS object. AngularJS is an example of when specific steps for setting up your test scripts are provided in the MV* frameworks documentation. In this example, you’ll unit test the AngularJS version of your calculation utility. In the Backbone.js version of your application, your calculations were in a model housed in an AMD module. In the AngularJS version, your calculations are in an AngularJS service component of an AngularJS-style module.

When the application is running, AngularJS’s dependency injection mechanism will automatically hand you instances of the objects you need. But because you’re running your tests outside the application, you must manually invoke the dependency injection. There are several ways to manually inject AngularJS objects. This is just one of them:

var injector = angular.injector([ 'ng', 'tipcalculator' ]);

You’ll need to pass in the AngularJS core module ng and the name of your application as dependencies for the injector. Then in your setup you can use the injector to get an instance of your calculation service:

beforeEach: function() {
   this.CalcTestSvc = injector.get("calculateSvc");
}

Now let’s look at the complete unit test for your calculation service (see the following listing).

Listing 8.9. Unit test for an AngularJS service

In figure 8.13, you can see that the tests did indeed run, which means the extra step of using the AngularJS injector worked.

Figure 8.13. QUnit test report showing tests run for an AngularJS service

With the injector at your disposal, you can run tests on any AngularJS object that you need to in order to unit test your application’s code.

8.3.4. Testing changes to the DOM

At times you also might need to test modifications made to the DOM in your SPA. In your tip calculator, you’re using the render() function of the view to reflect the state of your model in the UI. To test that your calculator’s output is propagated to the DOM accurately, QUnit provides a DIV element that has an ID of qunit-fixture. This element, referred to as a fixture, can be used to append DOM-related output. QUnit automatically cleans up the fixture element after each test, removing anything that’s been added. The following listing shows the setup and teardown for your tests on the view.

Listing 8.10. Setup/teardown to perform fixture testing on a Backbone.js view

To perform unit testing in the UI, you can check for the existence of DOM elements, CSS classes, or certain text. The next listing gives an example.

Listing 8.11. Unit testing your tip amount output by a Backbone.js view

We’ve covered a lot of ground with QUnit. It’s a great testing framework with many more capabilities than I can cover in a single chapter. But even when you have a powerful JavaScript testing framework like QUnit, you may still want (or need) to use one or more other frameworks for particular tasks.

8.3.5. Adding other testing frameworks to the mix

Sometimes not all of your testing needs are covered in a single JavaScript testing framework. That’s OK, though. It’s common to augment your main testing framework with a testing utility framework. To give you a brief example, let’s pretend that at some point you added the ability to save the tip and bill amount entered by a user for trending purposes. This is stretching things a bit. But nevertheless, let’s just pretend to illustrate this point. You’ll use our Backbone.js version again for this one.

You learned at the beginning of the chapter that you don’t want to include live server calls in unit tests. So what can you do? As it turns out, JavaScript frameworks/add-ons can give you the ability to mock a server call easily without having to modify your code. One such testing software is called Sinon.js.

Supplementing QUnit with Sinon.js

The purpose of the section isn’t to cover Sinon.js. Like QUnit, Sinon.js is powerful and has many great features in its own right. In this section, I’ll show how easy and painless it is to use other testing frameworks to extend your unit-testing arsenal. In this section, you’re going to supplement QUnit with Sinon.js to mock the server call of your new (pretend) feature. You’ll need to download the framework and add it to your code base. The software can be found at http://sinonjs.org. You can add it alongside QUnit in your test directory (see figure 8.14).

Figure 8.14. Your test directory after adding your second JavaScript testing framework

You won’t go through the motions of creating server code for this example, because it’s illustrating how to fake it out anyway. This will save you from having to set up a server and server-side code for one simple example. Instead, imagine you had a server call already working that’s used to save user input in your tip calculator. To create a mock server call, you first ask Sinon.js to create a fake server (see the following listing).

Listing 8.12. Create a fake server to mock server requests

You can add that command to your unit test setup. With the fake server created, you can tell Sinon.js how you’d like for it to respond. Keep in mind that you’re not testing the fake server’s output, because you’re mandating how you want the fake server to respond for your unit-test scenario. You’re testing the business logic related to the call. This could be whether the call was created or initiated properly or maybe how your application behaves, given different types of server responses. The following listing shows a mock server and a couple of simple unit tests using its response.

Listing 8.13. Using a mock server in a Backbone.js model’s unit test

Sinon.js has many other features that make it a powerful, standalone product. As you can see, it can also be the perfect companion to other testing frameworks such as QUnit. Because we’ve broached the topic of other frameworks, I’ll mention a few others you might want to explore. I’ll also include QUnit for comparison.

Making JavaScript unit-testing choices

Though not an exhaustive list, table 8.2 lists a few of the JavaScript testing frameworks that are popular at the time of this writing and that support unit testing.

Table 8.2. Popular JavaScript frameworks that support unit testing

Name	URL	Comments
QUnit	http://qunitjs.com	Mature framework, lots of other features I didn’t get to cover in this chapter, easy to set up and use.
Mocha	http://mochajs.org	Mocha has many features but leaves it to you to pick an assertion library such as Unit.js (http://unitjs.com) or Chai.js (http://chaijs.com).
Buster.js	http://busterjs.org	Though still in beta at the time of this writing, this framework contains many promising features.
Jasmine	http://jasmine.github.io	Another easy-to-use framework, but this one is focused on behavior-driven development.

Don’t be afraid to explore other frameworks even if you’ve found one that’s your favorite. Others might have particular strengths that supplement your preferred framework.

8.4. Chapter challenge

Here’s a challenge for you to see what you’ve learned in this chapter. Create a small survey SPA that could be used to poll users on what they like best about a particular topic. The topic could be which movie is the best, which food, and so on. The output should keep tallying the results with each survey submission, showing how each item in the survey is ranked. It can be as simple or as complex as you’d like. Then, using either a JavaScript unit-testing framework covered in this chapter or another that you like better, create a suite of unit tests for your application.

8.5. Summary

You made it through a crash course in client-side unit testing. Let’s review what you learned:

• A unit test is performed on the individual parts of your code. This could be an entire module but is often individual functions.
• Unit tests provide examples of how your code works.
• Unit tests should be focused on individual concepts related to the behavior and purpose of the software.
• Unit tests shouldn’t require any particular order, should be self-reliant, and should be easily understood.
• One approach to creating unit tests is to create the tests after the software is written.
• With test-driven development (TDD), the test is created first.