Dr Nic

Dead simple JavaScript Unit Testing in Rails

Skills Matter : Rails Underground 2009: on Dead simple JavaScript Testing

Formats: Video/Screencast (410 Mb, torrent) | Video only (vimeo)

Start downloading the torrent now, read this article 37 times and the video might be ready to watch.

Writing tests are great for helping you design and think out your code, and the bonus is you end up with a test suite to aide in fighting against regressions. Why? It’s embarrassing when your JavaScript doesn’t work in production.

But how do you get started with testing JavaScript? How do you make it easy? I mean, so easy that you’d feel stupid to not write tests?

And how do you know if your designer/HTML-chopper has broken your JavaScript? How do you find out if JavaScript is broken in CI builds? And what is the appropriate punishment for designers who break JavaScript?

Finally, it is now uber easy to get started: the blue-ridge plugin for Rails. (I previously discussed it near the bottom)

To spread the word, I travelled to London, England for the Rails Underground conference a few months ago. The presentation is now online (recorded and published by SkillsMatter).

I was also recording the screen during the presentation and we’ve composited the two together (a la confreaks) and it’s available via BitTorrent. If you can seed for the next few days, that would be greatly appreciated too.

The talk is 45 minutes and questions are 6 mins. (I sadly don’t repeat into the microphone some of the questions because the room acoustics were good and everyone could hear everyone else’s questions. Sorry.)

Go get it now.

Why Blue Ridge?

This recording was done in July 2009, a few months ago. Is Blue Ridge still the bees-knees? I think so. It has issues, edge cases and bugs, but I don’t think there is a similar nor better Rails extension that includes (out of the box) a headless test runner, a bundle of test libraries (Screw.Unit, Smoke, etc), Rails generators, and automated discovery of “the designer broke our JavaScript!” lynch-mobbing (see my branch below).

These are the things I want. If there’s a better testing environment (say on HTMLUnit instead of env.js), then I think the killer packaging is to bundle it all up, with the features above, so it is drop-in, dead simple to use.

My history with JavaScript testing

In the introduction I talk about my life with JavaScript and testing. Here is the extended summary if it’s interesting to you at all:

  • 2005:
    • ASP.NET + Ajax == “crapola”
    • Rails promo: “easier to do Ajax than not to”
    • Inline JavaScript helpers
  • 2006:
    • RJS to generate JavaScript
  • 2007:
    • JavaScript only in its own files
    • Unobtrusive JavaScript
    • Got myself into terrible mess with MyConfPlan
    • How to test JavaScript?
  • 2008:
    • Figured out how to test it
    • Write a PeepCode but never published it
    • Wrote newjs and jsunittest
  • 2009:


I mention a couple of miscellaneous things. Here’s a summary.

My fork of blue-ridge has the feature to render sample HTML from your templates. It wasn’t accepted into the primary blue-ridge library because it was rspec only. Perhaps someone can make it work for test/unit etc.

I alias the script/generate command:

alias gen="script/generate"

I’m extending TextMate with Ciarán Walsh’s ProjectPlus plug-in (source). It’s sweet.


Thanks to Mark Coleman for organising Rails Underground, inviting me over, and having the sessions recorded. And to SkillsMatter for recording and publishing the raw footage.

Thanks to Bo Jeanes for helping to get Final Cut Pro to mash the screencast and the SkillsMatter video into one video.

Thanks to Jack Chen for hacking some code to push the video up to s3 (when Transmit and BaconDrop were failing me)

Related posts:

  1. Using CoffeeScript in Rails and even on Heroku I’m pretty excited about CoffeeScript as a clean-syntax replacement for...
  2. First look at rails 3.0.pre This article is out of date in some aspects....
  3. Rails themes can remember things I was getting annoyed at having to remember all the...
  4. Install any HTML theme/template into your Rails app Have you ever even bothered to Google for “rails...
  5. Closing in on The Dream: “one-click-to-deploy Rails apps” Got a simple app you want to build? Allocate...

13 Responses to “Dead simple JavaScript Unit Testing in Rails”

  1. Social comments and analytics for this post…

    This post was mentioned on Twitter by RubyReflector: Top Ruby Article: Dead simple JavaScript Unit Testing in Rails: Formats: Video/Screencast (410.. http://bit.ly/1BzaNP...

  2. Nando Vieira says:

    Have you considered JSpec (http://jspec.info)? From all the frameworks I have tested, JSpec was the best one… it has jQuery integration, a syntax similar to Ruby/RSpec and is being actively developed.

    I’m using it in all my latest projects!

  3. For those wanting to just dip their toe in the JavaScript testing water, I wrote a Rails plugin that allows for easy setup and functional testing of JavaScript using QUnit from the jQuery folks. I tried to make it extremely easy to use thinking it was more for people new to JS testing:


  4. Just get online today and you will see what is all about, they have the most beautiful stuff that you have ever seen, check it out, you won´t regret it.

  5. [...] 13th, 2009 Dr Nic ’s Dead simple JavaScript Unit Testing in Rails (tags: javascript testing rails tdd bdd video js) How To Start A Rails Edge App The Easy Way | [...]

  6. Micah Geisel says:

    Regarding the problem concerning DOM transactions, perhaps we could set up the initial state (events and all) inside of an iframe. Then, before each test, we could use $.fn.clone(true) to copy this state (events and all) into the main html file.

    What do you think?

  7. Dr Nic says:

    @micah, I think someone else mentioned the $.fn.clone method after the session. I completely forgot about it til now. It could be quickly tested in a before/after block pair before being imported into blueridge.

  8. Micah Geisel says:

    it works! i had to wrap the html fixture in a div.fixture to avoid stomping on the test runner’s html, but this could be avoided by integrating these changes directly into blue ridge.


    ive never really had anything worth contributing back until now, how best to proceed? open a dialog with relevance?

  9. Dr Nic says:

    @micah, the minimalistic option is to drop a note in the Issues tracker for the project on github with your gist etc. Hopefully someone else then decides they want to do all the work of writing unit tests etc.

    Or, it’s a great opportunity to have a look in the blue-ridge project, figure out where you could write unit tests to test that “if I have a spec that is destructive to the DOM, the next spec still sees the original DOM” for example.

    I think I did attempt to do this once, and couldn’t figure out how I hooked stuff into Screw.Unit. Yeah, it didn’t seem obvious at all. You might need to ask a screw.unit person for help.

    Definitely a great patch though if you can wire it in!

  10. [...] Dr Nic ’s Dead simple JavaScript Unit Testing in Rails [...]

  11. [...] and I have a lot of respect for their code. There are other blog posts (Jason Rudolph’s and Dr Nic’s) that outline the inner details and usage of Blue Ridge (it packages other tools, such as [...]

  12. Amy says:

    @micah, I think someone else mentioned the $.fn.clone method after the session. I completely forgot about it til now. It could be quickly tested in a before/after block pair before being imported into blueridge.

  13. [...] não conheçam o Blue-Ridge, o Dr. Nic publicou faz um tempo um post onde explica a ferramenta e onde também publicou o video de uma palestra que ele deu no Rails [...]