Small update to AppConstants
Jun 14

What’s the difference between your application’s javascript code and its java/ruby/python/whatever code?

Think about it for a second. Done? Well, the answer is: none!

In today’s web applications your javascript code is no different from the rest of your code base but yet we treat it with disregard - and we’re all to blame.

We often see developers investing time writing all sorts of automated tests around their code base but fail to do the same for their javascript - and yet they get surprised when their client can’t click on a button on their web app that depends on that ajax call that has been manually tested once when the page was first released.

Ask yourself this question if you’re not sure if you should be testing your javascript: If it breaks, can my users still benefit from my app? - I think the answer for most web apps is obvious.

As for tools, I can only speak of two, JsTestDriver and screw-unit, the latter being the one we’re using in my current project at ThoughtWorks.

What I liked about screw-unit is that it’s very easy to get it up and running. Being a Behavior-Driven Testing Framework it’s not surprising it has a syntax similar to Rspec -which I prefer over JsTestDriver’s similarity to JUnit’s.

Take this class as an example:

function Greeter() {
  this.greet = function() {
    return "Hi";
  }
 
  this.render_hi = function(container) {
    $(container).text('Hi there!');
  }  
}

This is how a test written with screw-unit could look like:

Screw.Unit(function() {
  describe("Greeter", function() {
    it("should say Hi", function() {
      greeter = new Greeter();
      expect(greeter.greet()).to(equal, "Hi");
    });
 
    it("should render the message 'Hi there' inside the container div", function() {
      dom_test = $('#dom_test');
      dom_test.html("<div id='container'></div>");
 
      greeter = new Greeter();
      greeter.render_hi('#container');
 
      expect($('#container').text()).to(equal, "Hi there!");
    });
  });
});

Not too bad for a javascript test suite huh?

So the next time you write a javascript line of code, how about writing a test for it? Consider using screw-unit as your tool but if you have been writing tests using a different framework and you’re happy with it, share your experience.
I’m always keen to learn better ways of doing what I do.

Cheers!

Related Posts

4 Responses to “Are you testing your javascript yet?”

  1. Diogo Baeder says:

    Also, check out QUnit, which is a dead-simple unit testing framework without external dependencies (not even jQuery), maintained by Jörn Zaefferer and John Resig. It’s a great tool! :-)

  2. Thanks for the tip Diego!

    I’ll make sure I take a look at it!

    Cheers

  3. Leonardo,

    Do you think writing GUI automated tests pays off?
    How have been your experience with it?

    I’ve been having great results while adopting TDD for application’s core code and writing integration tests that don’t pass trough the GUI.

  4. Hi Rafael!

    I believe both types of tests - Integration and GUI (I’m assuming you mean acceptance by this) - are important and give us different feedbacks.

    Integration tests tells us about the internal quality of our code - how easy it is to deal with - while acceptance tests is all about external quality. Without them, your interface can break and your tests won’t catch anything.

    But then where does JS unit test comes in? If you have good acceptance tests, they make sure your JS works, but they’re slow and you lack that internal quality feedback again.

    In our current project here at ThoughtWorks we have an extensive suite of unit, integration and acceptance tests and I gotta say, each one of them pays off. :)

Leave a Reply

preload preload preload