Testing the javascripts


The Stickies Project is a fairly straight-forward, resource-oriented application that sits in the sweet spot for Ruby on Rails. The three main resources (users, projects and stickies) don’t require anything fancier than the standard CRUD operations with validations. Making use of James Golick’s excellent ResourceController gem makes the backend portions almost custom-code-free, and by sticking with a strict resource-oriented design, we can treat the server-side code as a datastore. In this case, our application code moves up a layer to the browser making JavaScript our primary development language for the stickies project. Since the heart of our application is in JavaScript, it would be irresponsible of us not to focus our design and testing efforts on it. But…but, I don’t know how to do that in the javascripts! It is going to slow me down. Well, should I make a plea to the all-holy god of ‘being pragmatic‘ and cover up my lack of skill? Hellz to the no! Let’s get started learning and, shock of shocks, maybe even practicing a bit, so it doesn’t slow me down in the future!

This post will discuss my experiences setting up and trying out the Blue Ridge JavaScript testing environment.

My previous experience with testing JavaScript was almost non-existent (I did a tiny bit with my own assertEquals function), so it was time to settle down and do some learning. There are a lot of JavaScript testing solutions out there, but, based on my knowledge of the maintainers, I chose to use Blue Ridge by Relevance Software. I know those guys, having spent a couple months working with them, 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 ScrewUnit, to form the whole solution), so I’ll just write here the steps I took to set it up. I was a bit nervous about what effort it may take to get it up and running in my app, but, as you’ll see, it was trivial to get my first tests running. By no means am I a ScrewUnit expert, having only written a few tests now all in the form expects(x).to(equal,y), but after only a couple minutes of investigation, I had a test up and running in my own system.

Note: I know that Blue Ridge wraps a lot of other frameworks in a nice package, so some things that I attribute to Blue Ridge might actually be part of ScrewUnit or env.js or Rhino or Smoke, but I haven’t done the deep-dive to figure out which parts are which. So, for the sake of my sanity and time, I’m going to just say everything is part of Blue Ridge. If I mention some feature that is part of one of the packaged frameworks, feel free to put a comment here that sets the record straight.

I want to stress that, while I’m learning the framework, I am doing a combination of test-first and test-while programming, not TDD. In other languages, where I am comfortable with the tools, I live in a fairly strict BDD workflow, but I’m still getting used to the tools here. So, as JB Rainsberger talks about, I’m still at the point of worrying about testing and not ready to listen to what they are telling me about my design. Also, while I’ll be looking at jsSlim in the future to fill the heart-shaped hole in my chest that keeps me from doing a nice BDD workflow in the javascripts (I worked on the original RubySlim implementation, so I have a sweet spot in my heart for slim. Plus, I saw Uncle Bob talk about the latest and greatest things in FitNesse last week at the Columbus Ruby Brigade, and I must say that I am pretty damn impressed), I don’t have the tools, yet. So, I’m starting at the beginning and building up to TDD.

Setting up Blue Ridge

Holy Shit! Talk about easy to setup. I followed the instructions in the readme in the project, and, what do you know, they were right. Here’s a summarized version of them:

  1. install the plugin (command)
  2. generate a spec file for your js file
  3. run rake spec:javascripts
  4. add spec:javascripts to my default rake task

Note: application_spec.js
It is worth mentioning that I deleted the application_spec.js file. I usually delete my application.js file when I init a new rails app, as having it there sets a bad precedent as a dumping ground for the javascripts. I like to keep mine organized, just like I do in other languages, so, since we were dealing with stickies, I generated a stickies_spec.js to go along with the stickies.js file.

HTML Fixtures

A nifty part of Blue Ridge is the html fixtures. They provide a dom that I can configure in my own way to test out my codes. It was nice to use it as a proving ground for the structure of my html, which I could then use as a concrete example when building my views. A happy side-effect was that it showed a few places where I felt the need to write a view spec. This was surprising to me, as I generally don’t write them.

For example, the main user-interface element is the sticky. The visual representation of the sticky is a div.sticky, and, especially since we were still building towards the appropriate javascript abstraction, it was important to have a good schema for the it. When posting new content (using the inline editing component jEditable), we needed to have the uri for updating the sticky. Being a good little boy, I decided that it should be generated on the server and passed with the sticky, so I needed a place to put it that was accessible. The sticky content was a child div (.editable), and I first put the uri as @data-update-url at this level, but, as I was writing the javascripts for posting any new content to the update uri, it became clear that the update url was not associated with the content, but was related to the sticky, itself. So, up it moved to the .sticky div. This seemed pretty important to me, so I quickly generated a view spec and wrote an example for showing that the @data-update-url was being correctly populated on the div. As expected, it failed, so I jumped over the view and moved it to the correct place. Growl growled at me that all was green, and, appropriately enough, the birds started singing happy songs about the green bars of lore.

HAHA! I just told Sarah “a couple paragraphs above, I mentioned that I wasn’t doing TDD with javascript, then I realized that I wrote a paragraph about how my tests recommended some design improvements.”

Well, that’s it for now. I’ll be writing more blog posts with details about testing the javascripts later!


One Response to “Testing the javascripts”

  1. Caleb Says:

    Looking forward to this series! I’ve been wanting to give Blue Ridge a try for a bit so I’ll be looking forward to how you are testing the JavaScript.

Comments are closed.

%d bloggers like this: