At the Forge - Testing JavaScript

A look at Screw.Unit, a framework for JavaScript testing.

The test is passed when Screw.Unit() is executed. If it works well, the body of the HTML document is modified accordingly, using CSS classes (defined in screw.css) that give the traditional green (for passing) or red (for failing) report on the tests you performed.

I'm going to add two more tests, one that I know will pass, which uses the not_equal test modifier. The other test will fail, so you can examine what it looks like when one does. If all goes well, you should see two green bars and one reddish-brown bar, the last of which indicates failure. The test itself looks like this:


<script type="text/javascript">
     Screw.Unit(function() {

       describe("Triple should triple", function() {
         it("returns 6 for 2", function() {
           expect(triple(2)).to(equal, 6);
         });

         it("does not return 100 for 2", function() {
           expect(triple(2)).to_not(equal, 100);
         });

         it("does return 100 for 2 -- fail!", function() {
           expect(triple(2)).to(equal, 100);
         });
       });
     });
</script>

As you can see, you can include as many it statements inside a describe block as you need. Over time, you will see your spec grow to contain more and more descriptions, it statements and expect statements.

Checking the DOM

Testing JavaScript functions is certainly a good thing to do. However, one of the primary uses of JavaScript is to modify the DOM—the document object model that provides a handle onto the contents of an HTML page. Using the DOM, you can view or modify the page, both in its tags and in its content.

Thus, DOM manipulations are a primary target for JavaScript tests. You want to be able to say that when a particular piece of HTML is clicked on, another piece of HTML should appear.

Now, some of the documentation for Screw.Unit will tell you that you can (and should) use a click() method to simulate clicking on an element of your page. I not only found the click() method to be unreliable, but also was persuaded by a posting on the Screw.Unit mailing list to put my text-hiding code in a separate function, which can then be called from within the click() handler for the paragraph and also from the test within an it block. This not only worked, but also encouraged a style that is more readable and easily workable, in my opinion.

The full file, clickview.html, is in Listing 2. The idea is that the document contains a paragraph:


<p id="hideme">Click to hide</p>

You then attach a click() event handler to the paragraph, invoking a function when the paragraph is clicked on:

function hide_paragraph() {
        $("#hideme").hide();
}

$(document).ready(function() {
    $('#hideme').click(function() {
        hide_paragraph();
    });
});

Finally, you set up a Screw.Unit() test block, as follows:

Screw.Unit(function() {

  describe("Paragraph", function() {

    it("should be hidden when clicked", function() {
      hide_paragraph();
      expect($('#hideme').is(':hidden')).to(equal, true);

    });
  });
});

When you load the page, Screw.Unit first invokes the function hide_paragraph(), which has the same effect that clicking on it would have. Then it checks to make sure, using a pseudo-class (:hidden) to identify hidden text. If no text with the ID “hideme” is currently hidden, jQuery returns an empty list, and the assertion fails.

The fact that everything in Screw.Unit, as in jQuery, is done using CSS selectors makes it easy and fast to work with. It would seem that there are people doing TDD (test-driven development) and BDD (behavior-driven development) using Screw.Unit; although I don't count myself among those, I do see myself using this sort of testing in the future, if only to avoid egg on my face among my software users. Besides, testing JavaScript in this way, at least to my mind, gives me a feeling of working on serious software, rather than one or more basic hacks.

I should note that the style in which I presented Screw.Unit in this column is a concise, but not idiomatic way that most users will put it into practice. Screw.Unit users typically separate tests into multiple files, allowing them not only to define custom test matchers, but also to have an entire library of tests, rather than just one file. Once you get started with Screw.Unit, I'm sure you will find a style that suits your needs, without running too much against the grain of the system's expected use.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix