Are you part of the vast majority of people who don't bother with testing their JavaScript code? Mark Bates, author of Programming in CoffeeScript, has written in JavaScript for years, but admits that he only recently began testing it. In part 1 of this series, see why your familiar arguments against testing your JavaScript no longer wash.

From the author of

From the author of

A good developer today tests his or her own code. The old arguments—"It's too hard to set up," or "I don't know how to test my code"—just don't cut it anymore. Testing tools have never been easier to set up, configure, and use.

One community that has embraced testing is that of my beloved Ruby/Ruby on Rails. When Rails first appeared on my radar in late 2005, I was well and truly embedded in Java land. I wrote a lot of Java code, and I like to think that I was pretty good at it. But I didn't write many tests for my Java code; my method of testing essentially consisted of refreshing the browser a lot.

One of the first things that struck me as interesting about Ruby on Rails, apart from Ruby (which blew my mind), was that a test framework was built right in! When I generated a model or a controller, a corresponding test was generated for me. Not only did Rails make testing my code easier; it subtly pressured me to write tests. My eyes opened and I saw the light. From that point on, everything—and I mean everything–needed to be tested. Except for my JavaScript.

Wait, what? That's right. I went for years without testing my JavaScript code. Chances are you don't test yours, either.

A Sad State of Affairs

Around the beginning of 2012, I gave a presentation for the Boston Ruby Group, in which I asked the crowd of 100 people a few questions. I began, "Who here writes Ruby?" The entire audience raised their hands. Next I asked, "Who tests their Ruby?" Again, everyone raised their hands. "Who writes JavaScript or CoffeeScript?" Once more, 100 hands rose. My final question: "Who tests their JavaScript or CoffeeScript?" A hush fell over the crowd as a mere six hands rose. Of 100 people in that room, 94% wrote in those languages, but didn't test their code. That number saddened me, but it didn't surprise me.

Why wasn't I surprised by the low number of people testing their JavaScript? Because, until about a year ago, I was one of those people. My arguments for not testing my JavaScript code were the same ones everyone else offered: "It's too hard to set up," "I don't know how to test my code," and the big one, "I don't do much with JavaScript anyway, so why should I bother?"

You've probably said those same things to yourself at one point or another. You've rationalized your lack of testing. Well, no more. The cycle ends right here, right now.

What caused me to kick myself into gear and start testing all of my JavaScript code? Well, two things, actually. First was CoffeeScript. Suddenly my code read more like Ruby and less like JavaScript. Things seemed to make more sense. My code was clearer and better defined.

The second thing that changed was a direct result of my love of CoffeeScript: I started writing JavaScript-heavy front-end applications. For years I stayed away from doing all but the most minor of AJAX queries. JavaScript didn't have a structure, it was messy, and it was very hard to test. But now, between CoffeeScript and Backbone.js, my front-end code was easy to write, it was well structured, and it was fun!

Once I realized that I was writing the majority of my applications in CoffeeScript, I told myself that I needed to start testing this code like I did my back-end Ruby code. That led me on a hunt to find some great tools for the job.