TDD with jQuery thoughts

I've recently been redeveloping a javascript-heavy section of a project without any frameworks other than jQuery. To do this, I've been doing TDD heavily with Jasmine, but I'm not very happy with how I've managed to isolate the tests from the DOM and jQuery manipulation. My current process is to inject a 'fake' jQuery into the application constructed of Jasmine test spies, which works well enough but doesn't give very good granularity on ensuring that the jQuery calls have been made on the correct objects.

I'm curious as to what other people have done in similar areas. We now have > 300 tests on the javascript in this project, of which my new development currently constitutes about 100. The test suite as a whole (and tied to the DOM with jQuery) takes  ~2 minutes to run, but my new isolated tests run in ~1s so I'm interested in pushing the isolated approach forward for unit-testing. I could make my fake jQuery more feature-rich and able to track more detail, but I'd like to know what others are doing in this area before potentially reimplementing something that already exists.

jsPlumb

jsPlumb is a pretty cool library for 'plumbing' a web page. It allows the drawing of arbitrary connectors between HTML elements using straight connectors, flowchart style connectors or some nice-looking Bézier curves, giving some effects like this:

Screenshot of the jsPlumb jquery demo

I've been using jsPlumb in a recent project to draw some fun visualisations in conjunction with meteor.js and my thoughts on jsPlumb are very positive. jsPlumb is fast to load, draw and redraw connections, it integrates with various different JS frameworks and it's pretty simple to use. About the only criticism I have is that it would be nice if you could influence the connection routing with a bit more precision, or simply have the ability to set up some elements that the connector should try to avoid.

Integrating the library with meteor.js was as easy as placing the jquery jsplumb plugin file into the client/lib directory of the project.

RSpec with Turnip on Gentoo

Turnip is a cool RSpec extension, bring the goodness of Gherkin business readable DSL. But - like Gherkin - it's sensitive to shell encoding. I run Gentoo, so to fix Encoding::InvalidByteSequenceError I use

export LANG=en_US.UTF-8

Thanks to stackoverflow

Meteor.js on Appfog

Meteor.js is a great JavaScript framework but it can be a little problematic to deploy somewhere other than the hosting provided by meteor.com, such as the cloud hosting PaaS provider appfog.

First was the task of getting the environment variables from Appfog to match up to the ones expected by Meteor. Meteor uses MongoDB, so first I added a MongoDB service on appfog. This is done easily by clicking on:

And selecting the MongoDB service:

This gives you MongoDB, but unfortunately the environment variables it exposes to your application aren't in the form that Meteor expects. To solve this, I added the MongoHQ add-on. Similar to before, I went to the add-ons section:

And selected the MongoHQ add-on:

I got a suitable URL environment variable when I added the 'MongoHQ' add-on, but the URL was under the name $MONGHQ_URL instead of $MONGO_URL. This is quite easily solved by going to the environment variables:

And setting up the following variable:

I also also set the ROOT_URL environment variable for my application as I wanted to generate absolute urls from meteor.

Previously, I also needed to set the PORT environment variable to $VMC_APP_PORT but this no longer appears to be necessary. If it is necessary for future deployments, the same process is used as for the MONGO_URL variable.

After the environment was correct, I encountered issues from the fibers package bundled with meteor. This was solved by removing the bundled package and reinstalling the fibers package from NPM with the bundled code. As this is needed each time, I wrote the following short script to automate the process (and also store the code that was released).

With this script in place, I can now deploy to Appfog reliably whenever I need to, without having to remember a set of file modifications.

Thanks go to http://blog.philkershaw.me/2012/06/deploy-meteor-to-appfog.html as the starting point for my deployment.

Internet Explorer Console Shim

Chrome is my weapon of choice when developing rich CoffeeScript and JavaScript apps. This means shaking out all those little differences with IE9 towards the end of a project, and learning to live with all sorts of foible.

Turns out that that IE doesn't always play well with console. In particular, on IE9 calling console.debug fails with

Object doesn't support property or method 'debug'

Since console.debug is deprecated, I took this opportunity to grep and replace console.debug calls with console.log but its wise to remember to add the console shim for troublesome older versions.

beforeunload events in Internet Explorer 9

Chrome is my weapon of choice for JavaScript development. This means spending a little bit of time with IE9 when development's almost over, learning to play with its little ways. We were taking beforeunload to display a dialog whenever the user risks losing data by navigating away — but only then. IE9 (oddly) displays null in a dialog when null is returned from beforeunload. Returning undefined instead means harmony amongst browsers. Another little trick to add to the playbook...

IE9 on Rails in Development

The asset pipeline is one of my favourite Rails 3.1 features. Assets — such as JavaScript and CSS files — are served as written in development mode. As a default, this is spot on but when debugging a rich app on IE9, I found some tuning needed. In particular, IE9 has a hard limit of 31 stylesheets. In this case, it's useful to switch on asset compilation in development. Read on to see how...

JSparklines is a cool JQuery plugin for drawing sparklines — small, in-line graphs. This library uses css injection. In development mode, IE9 raised an Invalid argument error when this was called. A little bit cryptic, but after a little digging, the cause turned out to be that hard limit. Time to tinker.

To serve fully processed assets in development: edit config/environments/development.rb, setting

config.assets.debug = false

Thanks Dennis Reimann for his clear example.