Jquery unit test

• How to get started unit testing your JavaScript
• The arrange-act-assert unit test structure
• Techniques to isolate your tests and components.
• Things you should consider when testing your jQuery UI widgets.

Javascript unit testing

Unit testing, functional testing, and performance testing of the client-side portion of a web application present different challenges than server-side testing presents. In addition to testing the structural layout of a page and basic application functionality, you may want to verify that animations execute properly, that a page with a large amount of JavaScript has no memory leaks, and that the application maintains its functional and performance expectations across multiple browsers.

As a web application developer, you will use JavaScript for the user interface (UI) logic in your application to dynamically build the structure, to enable or disable portions of your UI, or to load data in the background. Some of this functionality may rely on libraries you adopt, such as jQuery. You’ll want to be sure that each piece operates as you expect so that the application as a whole works as planned.

Unit testing allows you to verify that individual pieces work as you expect and provides a way for you to verify that they continue to work as libraries or tools evolve. For example, you may build a jQuery UI widget to manage a piece of your UI. When the next version of jQuery is released, you can quickly and easily verify that your widget is still working by executing the unit tests using the new jQuery libraries.

What to test

Now that you know how to write a unit test, the really important question concerns what should be tested. Generally, in a unit test you are trying to verify the functionality of a relatively small component, such as a JavaScript object or a jQuery UI widget. Each test verifies independent pieces such as whether a calculation happened correctly or whether the proper document object model (DOM) modification occurred.

When you are testing UI widgets, you may be uncertain about what should be tested. The basic rule of thumb is to test anything a designer would not change. Logic that drives the UI might be tested to determine, for example, that the proper navigation action was invoked, that an element had the proper class attribute applied (or removed), or that the correct event was raised. But, you would not test that a specific font value was set or a specific background color of an element was used.

Isolating Your Tests

Often your object under test will rely on other objects, functions, or libraries. You may have an object that makes Ajax calls to retrieve data. If you attempt to make Ajax calls when running the unit tests you might get unpredictable results because the server responding to the calls may be unavailable when you run your tests. Generally, you want to isolate your component from these types of problems.

When testing, you will also want to isolate your component from other objects you build within your system. In Mileage Stats, many jQuery UI widgets rely on a publish-subscribe object for communication. When you test objects with dependencies, you do not want to invoke the actual dependencies. If you did, you would be testing more than one thing at a time. Instead, it is important to test that the component attempts to invoke a dependency. The typical strategy for isolating your component under test is to supply an alternative component or function that the component calls instead of the real component. These alternatives may be referred to as fakes, doubles, stubs, or mocks. As it turns out, the ability to isolate your component in this manner also helps the overall design of your application because you will tend to create smaller, more focused components.

With a substitute object employed, you can verify that the correct calls were made with the right values. For example, when testing that the Mileage Stats data cache component makes an Ajax call with the appropriate URL, a mock ajax function is supplied for testing in the jQuery object (represented as the dollar sign in the example). In this alternate, we verify that the expected URL is invoked by the component.