Automating Unit Testing - J Query

You want to automate testing your applications and frameworks, maybe even benefit from test-driven design. Writing your own testing framework may be tempting, but it involves a lot of work to cover all the details and special requirements of testing Java- Script code in various browsers.


While there are other unit testing frameworks for JavaScript, we will take a look at QUnit. QUnit is jQuery’s unit test framework and is used by a wide variety of projects. To use QUnit, you need to include jQuery and two QUnit files on your HTML page. QUnit consists of testrunner.js, the test runner and testing framework, and testsuite.css, which styles the test suite page to display test results:

Opening this file in a browser gives the result shown in Figure:(Test result in a browser)

Test result in a browser

Figure : (Test result in a browser).

The only markup necessary in the <body>element is a <div>with id="main". This is required for all QUnit tests, even when the element itself is empty. This provides the fixture for tests, which will be explained in Recipe (Keeping Tests Atomic).
The interesting part is the <script>element following the testrunner.js include. It consists of a call to the test function, with two arguments: the name of the test as a string, which is later used to display the test results, and a function. The function contains the actual testing code, which involves one or more assertions. The example uses two assertions, ok() and equals(), which are explained in detail in Recipe (Asserting Results).
Note that there is no document-ready block. The test runner handles that: calling test() just adds the test to a queue, and its execution is deferred and controlled by the test runner.

The header of the test suite displays the page title, a green bar when all tests passed (a red bar when at least one test failed), a gray bar with the navigator.userAgent string (handy for screenshots of test results in different browsers), and a bar with a few checkboxes to filter test results.
“Hide passed tests” is useful when a lot of tests ran and only a few failed. Checking the checkbox will hide everything that passed, making it easier to focus on the tests that failed.
“Hide missing tests” is useful when you have a lot of tests that are just place holders, indicated by the test name “missing test—untested code is broken code.” This can be useful when you have a large untested code base and added place holders for every test that still needs to be written. In order to focus on tests that are already implemented, you can use the checkbox to temporarily hide the placeholder tests.
The actual contents of the page are the test results. Each entry in the numbered list starts with the name of the test followed by, in parentheses, the number of failed, passed, and total assertions. Clicking the entry will show the results of each assertion, usually with details about expected and actual results. Double-clicking will run just that test (see Recipe (Selecting Tests to Run) for details).
Below the test results is a summary, showing the total time it took to run all tests as well as the overall number of total and failed assertions.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

J Query Topics