1 - Overview

Rigorous unit testing is a key principle to modern agile development. Unit tests not only make it easier for other developers to understand and work with your code, it makes it easier for you to maintain your own code as well.

In the past, unit testing JavaScript has been a difficult process, primarily because the infrastructure needed to run unit tests required a lot of manual setup.

SproutCore makes unit testing far easier by bundling an integrated testing framework as well as a test runner right into the build tools. The testing framework is based on jQuery's QUint.

2 - How it Works

2.1 - Where Unit Test Files Are Stored

Unit test files are stored in a directory, tests, under your SproutCore application subfolder. For example, if your application is named hello_world, then the tests folder will have this project path: hello_world/apps/hello_world/tests.

If this folder doesn't already exist for you, then add it at this time.

2.2 - Adding Unit Test Files

When you create a code file using sc-gen, it will automatically generate the skeleton for a unit test that you can enhance to test your code file. Then simply open the test file and write some tests.

To add a unit test file manually, simply create it inside the tests directory.

See Adding a Unit Test for more information on this process.

2.3 - Writing Unit Test Cases

Once you've added a unit test file, write your unit test cases using the QUnit testing API. A simple unit test looks like this:

module("HelloWorld") ;
test("value of 'string' is 'Hello World', function() {
     ok(HelloWorld.get('string'), 'Hello World',  "has preset string");
});

See Writing a Unit Test Case for more information on this process.

2.4 - Running Unit Test Cases

The test runner is activated when you launch sc_server.

You run all the tests by simply browsing to http://localhost:4020/sproutcore/tests.

You can also test a subset of unit tests; see Running Unit Test Cases for more information.

3 - Getting the Most Out of Unit Testing

To get the best results out of your test running, you should get into the habit of adding unit tests for every major function in your application. It is not necessary to add unit tests for every single method you write, but you should make sure your unit tests cover the major pieces of your app that are stitched together with bindings. This is especially important for any complicated engines or for components with a large number of moving parts since they tend to break easily.

Assuming you have good unit tests, you should also make sure everyone in your team runs all of the unit tests at least once before committing any changes to your source repository. Try to never commit source changes that leave tests failing. This way unit tests will remain a useful check for every developer on the project to ensure they have not broken another piece of the code.

In order to achieve the best test coverage, you need to run your unit tests in every target web browser you intend to run your application in. For example, when we write SproutCore code, we will load the test runner in IE6, IE7, IE8, Safari, Chrome, and Firefox. Since running unit tests this many times can become very labor intensive if you try to do it before every checkin, usually the best thing to do is to run your unit tests before every checkin in only one or two browsers such as Firefox and Safari. Periodically you should set milestones in your project development where you will run through the unit tests on all browsers and fix anything that breaks unit tests for continuing with your development.

Above all, the most important thing about unit testing is to write and run your unit tests regularly. Unit tests are only useful if you maintain them. If you write too much code that is not covered by unit tests, they will not prevent enough errors for people on your team to use them regularly. Likewise, if you let your unit tests failing for too long, developers will look at test failures as "noise" and tend to ignore them.

4 - Moving On

Now that you know the basics of how to use unit tests, it's time to start adding unit tests to your project.

See Adding Unit Test Files »

5 - Changelog

• February 15, 2011: initial version by Scott Smith and Vibul Imtarnasan
• March 2, 2011: paragraph formamtting by Topher Fangio
• August 7, 2013: converted to Markdown format for DocPad guides by Topher Fangio

Chapters

1. Overview

2. How it Works

   • Where Unit Test Files Are Stored

   • Adding Unit Test Files

   • Writing Unit Test Cases

   • Running Unit Test Cases

3. Getting the Most Out of Unit Testing

4. Moving On

5. Changelog