Saving Time and Sanity with Javascript Tests


So you've written your app and it works great in Chrome. The interaction is crisp, the workflow is solid, and you're excited to go into the demo... when you find out at the last minute that it has to be demoed in a different browser that you've never tested with. With 30 minutes left before the demo, you fire up the site in the new browser, only to be confronted with errors, nonfunctional forms, and widgets that seem to have a mind of their own.

This was the situation I was in at a hackathon a couple years ago, and I didn't sweat it. I had followed good Test-Driven Design (TDD) practices from the start, so I had a suite of qunit tests already in place to serve as regression tests. I simply pointed the new browser at the tests, saw which low-level functions weren't behaving as I had expected, and fixed them with time to spare.

Now, while getting to be a TDD superhero on a team is a cool experience, by far it's not the only benefit of having a solid test suite. Writing the tests themselves often leads to cleaner, more focused code, written at a faster pace. In this session we'll explore some useful testing tools, and go through some TDD examples of how to write good tests in javascript.

comments powered by Disqus

Time & Location

January 23, 2013 — 07:00 PM
Scitent (Map It)