Unit Testing Your Code with QUnit
Problem
You want to ensure the robustness of your application or library. A part of this is per‐
forming unit testing, but you don’t want to create the tests manually
Solution
Use a tool such as QUnit to incorporate unit testing into your application at the earliest
possible stage. For instance, we’re interested in testing a new function, addAndRound():
function addAndRound(value1,value2) { return Math.round(value1 + value2); }
A QUnit test case could look like the following, which performs two assertion tests: equal, to test whether the function returns a value given as the first parameter, and ok which just checks the truthfulness (the truthy value) of the function’s return:
test( "testing addAndRound", function() { equal(6, addAndRound(3.55, 2.33), "checking valid"); ok(addAndRound("three", "4.12"), "checking NaN"); });
The first test succeeds because both parameters are numbers, or can be coerced into being numbers, and the function result is 6. The second fails when the function call returns NaN because the first parameter can’t be coerced into a number.
EXPLAIN
There are multiple types of tests, such as tests for security, usability, and performance, but the most basic form of testing is unit testing. Unit testing consists of performing tests of discrete source code units, verifying that the unit behaves as expected, and that operations on data provided to or returned from the unit also meet expectations. In JavaScript, a unit is typically a function.
A good rule of thumb when it comes to unit testing is that every requirement or use case for a function should have an associated test case (or cases). The unit test checksthat the requirement is met, and the function performs as expected. You can develop your own tests, but using something like QUnit simplifies the test writing.
Depending on how you’re using QUnit, you’ll need to add links to the library to your test page. If you’re using something like JS Bin, selecting the QUnit option adds all relevant script source files. At a minimum, you’ll need to add a link to the QUnit CSS file, as well as the script.
You’ll also need to add two div elements for the QUnit output. QUnit gives the following as a minimum QUnit test page:
<html> <head> <title>QUnit Example</title> <link href="qunit.css" rel="stylesheet"></link> </head> <body> <div id="qunit"> </div> <div id="qunit-fixture"> </div> <script src="qunit.js"></script> <script src="tests.js"></script> </body> </html>
The unit tests will be in the tests.js file. The QUnit website provides very good documentation on using the product, so I’m only going to touch on some of the more common components, demonstrated in the solution. The tests are included within an outer function named test(). This is the most com‐ monly used way to trigger the QUnit testing, and is used to perform a synchronous test.
The first parameter is a label for the test results, the second a callback function that includes the tests. QUnit supports several assertion tests, including the two demonstrated in the solution:
• deepEqual: Tests for deep, strict equality
• equal: Tests for standard equality
• notDeepEqual: The inversion of deepEqual testing for deep, strict nonequality
• notEqual: The inversion of equal testing for standard nonequality
• notPropEqual: Tests an object’s properties for inequality
• notStrictEqual: Tests for strict inequality
• ok: Tests whether first argument equates to true
• propEqual: Tests an object’s properties for equality
• strictEqual: Tests for strict equality
• throws: Tests if callback throws an exception, and can optionally compare thrown error When the QUnit test is run, a display is output to the page specifying which tests failed and succeeded, each associated with the test label passed to the assertions.
Writing Tests First
(((programming, TDD vs. BDD approach))Modern development practices have em‐
braced the idea of writing the tests before much of the functionality for the application
(and libraries) is written. This Test-Driven Development (TDD) is a component of the
Agile development paradigm.
TDD takes some getting used to.
Rather than a more formal structured programming
or waterfall project design, with TDD you define the tests, do some coding, run the tests,
do some refacturing to remove duplicate code, and then repeat the process until the
entire functionality is finished.
Previous approaches incorporated testing only at the
very end of the process, when much of the code has already been created.
The Microsoft Developer Network has a page describing a typical scenario. In addition,
there are several books and publications online describing both TDD and Agile software
development.
In addition, another well-known Agile component is behavior-driven development
(BDD), developed by Dan North. If you’re interested in utilizing BDD with your Java‐
Script applications, there is a tool, Cucumber.js, specifically designed for BDD in JS.
No comments:
Post a Comment