Let’s Code: Test-Driven JavaScript

James Shore presents a fascinating new screencast series
on rigorous, professional JavaScript development

Watch demo

Latest Live Episodes

  1. Fixing Encapsulation

    Mon, 20 May

    In the previous episode, we factored out an SvgCanvas class from our existing code. We took a few liberties along the way, so in this episode, we improve our abstraction to no longer leak implementation details. We also put tests around the class.

  2. The SvgCanvas Class

    Wed, 15 May

    In order for our PhantomJS test to check that a line has been drawn, we need to check the DOM to see that the right SVG elements have been created. Fortunately, we already have code to do that in our client test. We just need to make it accessible to our PhantomJS code. We choose to do that by factoring an SvgCanvas class out of our existing code.

  3. Housekeeping

    Mon, 13 May

    A short episode for some necessary tidying. We discover a better way to install PhantomJS, move our PhantomJS spike into production, then make some much-needed improvements to our build (mostly off-camera). When we’re done, the PhantomJS smoke test is an established part of our automated build.

Latest Lessons Learned

  1. Front-End Unit Testing in a Nutshell

    Fri, 3 May

    In recent videos, we’ve spent a lot of time on front-end testing. But how does it all tie together? What, exactly, should you do when test-driving front-end code? If you’ve been hoping for someone to just lay it all out for you, I have good news: this one’s for you.

  2. DOM Events, UI Testing Strategies, and Selenium

    Fri, 5 Apr

    Let’s say you want to write some simple client-side form validation code. How do you test it? In this episode, we take a close look at DOM Events, then consider three strategies for testing UIs: Robots (such as Selenium), Simulation, and Thin UIs. We demonstrate the strategies in code and discuss the tradeoffs of each approach.

  3. Unit Test Strategies, Mock Objects, and Raphaël

    Fri, 8 Mar

    It’s easy to test pure functions and stateful objects. But testing functions with side effects is much harder. We look at three strategies for testing side effects: Asking; Inspecting; and Injecting. We demonstrate the strategies with Raphaël, the vector graphics library, and discuss when to use each one.

Demo Video

A brand-new screencast about
Test-Driven JavaScript

What our viewers are saying:
I will be using it as *the* goto reference for
any JS development for some time to come.
It has the right number of details that you don’t get by
reading book but only working with exceptional people.
I like the variety of technologies used and the
complete integration of them shown together.
I like seeing *all* aspects of the development:
the dead ends, the surprises, the wins, etc.
Quality is excellent, and I love that I can
download them and not have to stream them.

JavaScript Needs Test-Driven Development

If you’ve programmed in JavaScript, you know that it’s an… interesting… language. Don’t get me wrong: I love JavaScript. I love its first-class functions, the intensive VM competition among browser makers, and how it makes the web come alive. It definitely has its good parts.

It also has some not-so-good parts. Whether it’s browser DOMs, automatic semicolon insertion, or an object model with a split personality, everyone’s had some part of JavaScript bite them in the ass at some point. That’s why using test-driven development is so important.

What is Test-Driven Development?

Test-driven development (TDD) is a technique for ensuring that your code does what you think it does. It’s particularly relevant for JavaScript, with its cross-browser incompatibilities and hidden gotchas. With TDD, you express your intentions twice: once as a test, and once as production code. If the two approaches don’t match, your tests fail, and you’ve caught a bug.

TDD is a great way of catching the majority of programming errors. It’s not perfect, of course—in particular, it can’t tell you when your assumptions are wrong—but it’s very good at catching the kinds of bugs JavaScript is prone to.

Who am I?

I’m James Shore. I’ve been building applications using test-driven development and other Agile techniques for over 13 years. I’m a recipient of the Agile Alliance’s Gordon Pask Award for Contributions to Agile Practice and I wrote a book called The Art of Agile Development.

What You Get

This screencast series focuses on rigorous, professional web development. That means test-driven development, of course, and also techniques such as build automation, continuous integration, refactoring, and evolutionary design. We support multiple browsers and platforms, including iOS, and we use Node.js on the server. The testing tools we’re using include NodeUnit, Mocha, expect.js, and Testacular.

All videos are DRM-free, viewable on the web and downloadable, and all source code is included.

The “Live” Channel

The series consists of two main channels. “Live” episodes are a live recording of the application as it’s developed, with commentary. I edit out dead-ends and time spent in research so each episode is focused and meaningful. Each “Live” episode is about 15 minutes long and comes out twice per week, on Monday and Wednesday.

The application itself is a real-time multi-user drawing application, developed from scratch and continually enhanced in each episode.

The “Lessons Learned” Channel

“Lessons Learned” episodes are for people wanting a refresher, a quick reference, or who simply want to catch up. They provide a distilled look at a specific topic, such as automating Lint, testing a Node.js server, or automating cross-browser testing. The goal is to provide maximum information in minimum time—typically 10-15 minutes per episode. “Lessons Learned” episodes come out about once per month, on Friday.

I have learned so much more than I expected.
I really enjoy your approach to screencasting and
wish the series wouldn’t end some day.