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, however, by bundling an integrated test runner right into the build tools. The build tools also come with an integrated testing framework based on jQuery's Qunit.
Adding a Unit Test
If you use the sc-gen tool to add new source files to your project, a paired unit test will often be added for you automatically. All you often need to do to add unit tests is to simply open the test file and add in some unit tests.
If you add a file manually, or if you want to add a new unit test file, you can do so easily by simply creating a "tests" directory inside your application or framework and adding the unit test file in there. See Adding a Unit Test for more information on this process.
Once you've added a file to contain unit tests, you can fill in unit tests using the QUnit testing API. We chose QUnit as the basis for our testing framework because the testing API is so simple. A simple unit test looks like this:
module("HelloWorld") ; // name the group of tests you are writing
test("value of 'string' is 'Hello World', function() {
ok(HelloWorld.get('string'), 'Hello World', "has preset string");
});
Running a Unit Test
Once you've written some unit tests, you can run them easily by visiting the built-in test runner. The test runner is available when you run sc-server by visiting http://localhost:4020/sproutcore/tests. This application allows you to test various apps, frameworks, and themes in your SproutCore project, including the underlying SproutCore framework that your project uses.
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 your unit tests failing for too long, developers will look at test failures as "noise" and tend to ignore them.
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 a Unit Test ยป
Comments (0)
You don't have permission to comment on this page.