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 on this Talk

Avatar-missing-icon-03 Anson Parker, 24 Jan 03:04 AM

good rap - low on acronyms. a nice balance between philosophy and practical coding.

Open-uri20120618-43-viidk4 Michael Holroyd, 24 Jan 05:03 AM

Heya Ben thanks for the talk! I suspect you know already -- but the choice of a fiddle.js clone as your test subject will probably confuse newcomers ;) I'd also say spend less time on the syntax/details of particular tools and more on the pro/cons of testing at the JS level vs. alternatives. Thanks for the references to specific tools and some insights from your experience!

Me Joe Masters, 24 Jan 05:43 PM

Ben, I enjoyed your talk too. I think you succeeded in appealing to different levels of experience. I've only been actively using JS for a couple of weeks and I was able to follow your slides and get some good tips out of your talk. Well organized flow to the talk too. I agree with Michael that it would be good to spend time on JS vs alternative levels of testing an application, but I did appreciate the syntax details which helped me feel I wasn't missing what was actually happening in the code.

Stringio gcallsen, 24 Jan 09:30 PM

Agreed with all above and thank you for making the inaugural speech!

One possible modification would be to use an example 'application' that you're able to actually complete within the course of the presentation. Clearly it wouldn't be complicated but, as Michael said, a fiddle-esq clone as an example is ambitious and potentially confusing. If your example app had a simple goal, such as allowing a user to enter a message to an input then displaying that message to the screen, then you could probably complete the 'app' and cover the same topics.

Overall, though, great job. As a person who is just beginning to try TDD this was very helpful and gave me a good basis to think about the pros/cons.

Have an account? Sign in or register.

Leave a Comment

Time & Location

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