Integration tests

Put simply, tests which stretches over two or more tiers in the application. Tiers may be modules in the code base or a database or search engine. There are no mocks involved in this approach but stubbing if necessary. I wont write anything you don’t already know, so I’ll leave it there.

Unit tests

1. As is widely accepted, tests a single unit (class if you will) entirely. This may require the developer to mock out any dependencies (passed either through the constructor (yay) or hacked by making protected methods in your implementation (yuk)). The number of dependencies on the class usually influence the number of mocks in the unit test,
2. Integration amongst a few classes that are tightly coupled together. Sometimes there is one entry point into a class which depends on a few more classes. For example, there may be a simple feature which depends on a bunch of XML processing, some transformations and eventually spits out some nice object for you to use. Sure the bits and pieces which make the whole thing work are unit tested in the traditional sense, but the class that provides the entry point should be? I think it should be tested more like an integration test, with each test hitting multiple classes. Its not quite good enough to be labelled an integration test, so I’ve made some wiggle room under the unit test umbrella. In my own mind at least :)

An important point though…

If there is too many dependencies or too much mocking, chances are the class isn’t doing much and just delegates a lot, which means more mocks and more detachment from reality.

Given this statement allow me to make a few points in regards to unit testing your Javascript code! More specifically, unit testing with jQuery.

jQuery is nice, I really like it. I also like testing my code, however its always a pain in the ass when it comes to testing any kind of Javascript! I’ve built (well, building) a testing framework for Javascript which attempts to help test your jQuery, called MimicJS. At this point the jQuery component of the framework needs to be addressed and probably removed, mainly for the reasons I am going to describe here.

If there is one thing I have learnt about Javascript recently it is that mocking jQuery is a bad idea. Those who have done it know the pain, and hopefully they will agree with what I am about to write. Some of you may never have done it before and are going to read all of this and will never mock jQuery. I envy you, you bastard.

Note: the answers (well, my answers) are at the bottom of this post. I decided to list the reasons for not mocking jQuery first, then come up with a solution at the end to bring it all points together.

Mocking jQuery is hard to do

Why bother mocking something that is hard to mock?

The way jQuery is written and works is quite extraordinary. Where most of us are used to the traditional class/method patterns, jQuery disregards all of that and instead uses Javascript to its advantage. Rather than bending Javascript to fit, it works with it. I guess you can look at jQuery as a giant Javascript DSL. Have you ever written an extensive builder in Java, say to create your domain objects? If so, have you ever tried mocking the builder out? Of course not! It may or may not make sense to, but I can almost assure you it would be complicated. So complicated in fact you may be enticed to just use the builder and forget about mocking it altogether…

I’ll now talk about my own experiences whilst creating MimicJS and working with jQuery. The most complicated part by far was attempting to mimic jQuery (you’ll have to have a look at the project yourself to know what im talking about. Do you like my marketing tactics?). Testing behaviour in Javascript is actually quite easy. Most developers who are too lazy to find a behaviour testing framework test the behaviour within the spec itself, it only takes a line or two. So developing mimic for more traditional testing was relatively easy. Testing the behaviour of jQuery was down right painful and also unpolished. If I were to keep that part of MimicJS around I would spend a large chunk of my dev time maintaining it. So for that, I will be removing it soon and replacing with something a little sustainable. You’ll read about it soon.

Mocking jQuery means fragile specs

So what if it is hard to mock jQuery? Some propeller-head will spend endless days and nights building a tool good enough. Well, I can tell you it wont be me :) (And im not admitting im any sort of propeller-head, I’d rather be called a geek). Lets say a tool good enough existed, why wouldn’t I just use it and be done with it?

I’m just making up syntax here, but if a tool good enough to test the behaviour of jQuery existed, this is what it would look like (more or less).

// Implementation
function display() {
    var html = '<span>I am now displayed, and this is the message.</span>';
    var fixedHeight = 200;
    $('#dialog').empty().html(html).show().css('height', fixedHeight);
}

// Spec
it('should display the dialog with a default message provided', function() {
    display();
    $.usingSelector('#dialog').should('empty').and().shouldAlso('show').and().shouldAlso('css', with('height', 200));
});

Now im going to change the implementation. lets say I call height() instead of setting the height using css(), my test is going to break.

// Implementation
function display() {
    var html = '<span>I am now displayed, and this is the  message.</span>';
    var fixedHeight = 200;
    $('#dialog').empty().html(html).show().height(fixedHeight);
}

Seriously obvious right? Its a simple change, however it doesn’t change the behaviour of the what “really” happens, only the behaviour of the call. This is a single isolated example, but in a large code base you do not want to be making these little changes. Some may argue against that, saying that the call has changed so the tests should fail. I disagree. Like I said the behaviour of what “really” happens has not changed. I’m not interested in maintaining unit tests to that granularity that give me no real benefit. If what “really” happens changes, then and only then should the tests fail. “really” “really” “really”. And don’t forget about BDD. Unless you have a spec that “should fail when I change the way the height is set on an element”, then these specs shouldn’t fail for trivial reasons.

And what about an upgrade to jQuery? You’ll upgrade and any serious breakages are going to be mixed in with useless ones, all of which need to be resolved. Wouldn’t you rather specs fail for good reasons only?

More to the point, if the spec was some kind of integration test it would never fail over small changes like the one shown…

Mocking jQuery means zero DOM interactions

Easily forgotten, mostly because everyone hates it but there is also a DOM involved in all of this. In fact most developers who say they hate Javascript actually hate the DOM. Given that, it sounds like a good idea to avoid the DOM at all costs yeah?

Not really. Whether developers like it or not the DOM is an integral part of the browser and your Javascript code base. Avoiding it while testing is simply going to make the pendulum swing the other way. You’ll end up with specs which mean almost nothing.

Check out this example. Its obvious that there is a selection of an element being made and the wrap function is being called.

// Implementation
function highlightingARow() {
    $('.row:first').wrap('<div class="highlight" />');
}

// Spec
it('should highlight the first row',  function() {
    highlightingARow();
    $.usingSelector('.row:first').should('wrap');
});

The important part in all of this is not that the wrap function is called, but that the element selected actually has the right element wrapped around it. I’ve chosen an example that would require (I guess) some difficulty to implement across multiple browsers. I’ve seen Internet Explorer do some wonderful things with the wrap function, to the point where it had to be implemented differently altogether. With a mocked out jQuery, this spec would never had failed!

Because jQuery has been told to do something doesn’t mean it has done it properly. It’s much better to assert against what actually happened, which means checking the DOM after the jQuery call of course.

And, once again, upgrading jQuery? How confident would you be with replacing an old version of jQuery with a new one, running all your tests with a mocked out jQuery and seeing all your tests pass? Like I said before, jQuery is a giant Javascript DSL. More specifically, a DSL for the DOM.

Mocking jQuery means no TDD

Developers love to boast the fact that they follow many of the Extreme Programming (XP) practices like Pair Programming, Continuous Integration and Test Driven Development (TDD). Not surprisingly, for various reasons its hard(er) to achieve some of these practices in Javascript land. What I want to focus on here is TDD.

Once again, here is the wrap example

// Implementation
function highlightingARow() {
    $('.row:first').wrap('<div class="highlight" />');
}

// Spec
it('should highlight the first row',  function() {
    highlightingARow();
    $.usingSelector('.row:first').should('wrap');
});

Its easy to see that what’s specified in the test is very close to what is described in the implementation. Let me ask this question. Are you going to write the implementation first, refresh your server (if you have to, this is where I have much love for rails) and jump on the browser and verify what you have written is correct? or are you going to write the spec first, then do all those things? jQuery involves plenty of tinkering and will take a few goes to get it right. It would take a jQuery genius to get any benefit out of writing tests first, at least when mocking jQuery is involved. Therefore it would be more beneficial to write a spec which describes what the DOM should look like once the code has been executed, then you can tinker until the spec passes no?

Mocking jQuery is …

I only thought of four things, and instead of changing the heading of the post to “Four reasons to avoid mocking jQuery” I decided to keep it at five because it is a round enough number. That and I’m a bit of a bullshit artist. If I think of a fifth one I’ll post it I swear. A friend of mine put it perfectly, I’m simply TDD’ing (Title Driven Development, no wiki page for that one sorry).

What’s the answer?

It comes back to what I spoke about originally in regards to integration tests, unit tests, and the other use of mocks. Some of us decided that the best what to unit test our Javascript is to mock out all dependencies, whether its dependencies we created or other API’s like jQuery. If we are dealing with unit tests then MAYBE mocking out jQuery is a good thing. But I’m not that big a fan of unit tests when it doesn’t make sense. I can assure you there is minimal gain in mocking out jQuery. If you are testing code that requires DOM interaction in anyway, then it should be classified as an integration test and interact with the DOM as expected.

Now that I am not mocking jQuery any more, here is the same wrap() example from earlier but re-jigged slightly, hopefully highlighting the benefits of taking such an approach. The syntax I am using is similar to what will be implemented in MimicJS soon enough.

// Implementation
function highlightingARow() {
    $('.row:first').wrap('<div class="highlight" />');
}

// Spec
it('should highlight the first row',  function() {
    $('body').empty().append('<div class="row"/>').append('<div class="row"/>');

    when.    highlightingARow();
    then.    expect($('row:first')).toHaveParent($('.highlight'));
});

As you can see I have a slightly more verbose test. I have used jQuery itself to set up the test data and have got my expectations based on the state of the DOM and not the behaviour of jQuery. Let’s revisit the four points above and see the benefits.

Mocking jQuery is hard to do. Not much to add here as there is no mocking going on. I can assure you though its much easier to add matchers such as ‘toHaveParent’ than it is to mock jQuery nicely.

Mocking jQuery means fragile tests. If I change my implementation to use a different framework or the name of the wrap function happens to change, then from what I can see my spec is still going to pass. Provided the first row has the parent highlight I dont really care how it is implemented, as long as the state of the DOM at the end is correct.

Mocking jQuery means zero DOM interactions. The issues here have been squashed completely. Because there is no mocking going on means we are interacting with the DOM, which is a good thing. We can upgrade jQuery and be confident the highlight feature hasn’t change its behaviour. We also have more flexibility when it comes to testing across multiple browsers. If the wrap function is broken in IE for example then there will be specs failing for IE and not other browsers. “reality” is tested.

Mocking jQuery means no TDD. It’s obvious when we are mocking out jQuery line for line that there is next to no TDD’ing going on. A trivial example like this its nice to be able to implement test driven, even if only to make yourself feel less dodgy when writing it. Going test driven can be tough for developers, no need to make it tougher by mocking out something as tightly coupled as jQuery.

What could have been?

In an effort to keep things light-hearted/introduce myself to the masses, I thought what better to write about than my two passions in life, basketball and IT. This blog entry will also double as the first of many which document a journey, if I somehow produce what I’m about to propose of course (don’t count on it, but it sounds like a good idea RIGHT NOW).

I wont waffle on for too long, but I will state that I spent much of my childhood glued to basketball videos, the same ones, over and over, dreaming of playing professionally one day. It wasn’t until I was reaching the latter stages of high school (and realised that I wasn’t going to be Michael Jordan) that IT became a big part of my life.

I follow basketball religiously. I check the scores, watch for trades, read the books, understand the history and understand the game. So while I will write mostly about techy stuff in this blog, my loyalties are equally as strong with the sport and you will find traces of hoops in what I write. After all, it does keep things a little more interesting for the writer :)

Now lets marry the two together.

As a developer I’m constantly thinking about cool and innovative things I can create. As most developer will attest to its easy to get caught up in something you are passionate about, sometimes even going to the length of doing more than thinking about it. In the end you mostly have a half complete job, at least that’s what I end up with. This was a big driver for me starting this blog as well, because I know that ill burn out after the initial excitement and end up with not much at all. At least through writing I get the thought documented for everyone to see (well at this point it will just be the people I force to read my blog :)).
 

The Problem

The Box Score from my iPhone.

When a basketball game is on I’m glued to the box scores and twitter, from my iPhone mostly. It’s frustrating as hell looking at Yahoo! Sports from my phone. I can never seem to zoom to the good stuff quickly enough, and find myself constantly zoomed at a specific section of the page. And NBA iPhone apps? There is not much out there (at least in the Australian store) and what is there is pretty crap to be honest. I haven’t found anything web-based that offers something better than the box scores on the major sports websites.

So…why not make my own?

YES!

Oh wait, I’ll get lazy and wont finish it, that’s right. Lets just crap on about it here instead (not to say I wont hack around, I will).

With the iPad’s recent introduction to market, the big push from Google (with Google Chrome and Android) and a few inspirational keynotes, HTML5 seems to have finally hit the technology mainstream. That means its time for me to get off my ass and read up about this stuff (which I have been doing), start dreaming up ideas and be part of the push for a better web.

For the record I never used to give the web enough credit on devices like the iPhone, and was always thinking in native application terms. That’s all gone now thanks to the iPad. It aims to offer a web experience unlike anything we can get on other devices, and appears equipped enough to make that happen. Six months ago I may have been thinking about my dream native iPhone NBA application, however the web is too powerful, too flexible and too open to ignore. Hence now I would only ever go down the native app road if it was an absolute necessity.

What is this HTML5 powered page going to do?

Here’s a quick rundown. A snapshot of how this (lets call it an application) is going to work.

• Screen-scrape the results off an NBA site, strictly for proof of concept. The data has to come from somewhere right? This is quite easy to achieve with Ruby, therefore let’s make the back-end a Ruby on Rails application,
• Strictly define the markup. It’s important to not get caught writing unnecessary HTML as it will make it harder to make this thing work across multiple platforms,
• CSS3 and lots of it. This is important for the same reason as writing strict HTML, plus the fact that you can do cool enough stuff that the use of images on the page can be minimised,
• iPhone and iPad (and maybe Google TV?) capable. Keeping this in mind is important as it greatly influences how the application is created,
• Some form of video (maybe a YouTube subscription which shows highlights of the days games).
• No scrolling, full screen (easy enough),
• HTML5 Web storage via local database. Allowing the capability of caching the play-by-play (when the users exits and re-enters the application), even complete box scores of previous games,
• The use of Canvas 2D, for drawing any specific shapes that may be needed for the application,
• A different experience on the iPhone compared to the iPad, they are different platforms afterall.

Now what?

Well, I may as well start hacking away and see what I can produce! I’ll do bits and pieces and post my findings along to way. Future posts will reveal more of course.

Thanks for reading and hello!

Much more interesting and exciting stuff to follow soon. Until then I will tinker with the look and feel of the site