Let’s Code: Test-Driven JavaScript

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

Watch Now

Recent Introductory Episodes

Updates Friday

  1. Small Steps and Meaningful Names

    Fri, 27 Nov ’15

    We continue to expand the capability of our little tab-switching library. Before, it could only hide one element. Now we stretch it out to support multiple elements, continuing to work incrementally, proving our work as we go. As usual, the hardest parts are figuring out how to take small steps and create meaningful names.

  2. Shims and Containers

    Fri, 20 Nov ’15

    Our class manipulation code is a bit clunky, but luckily there’s a DOM property that makes everything easier: the classList property. Unfortunately, it doesn’t work on all the browsers we’re supporting. We introduce the concept of “shims,” for making new features work on old browsers, then move on to refactoring our test cleanup code to use a container.

  3. Decoupling

    Fri, 13 Nov ’15

    Following last chapter’s introduction of TDD, we’re now ready to test-drive our tab library. Our first step, as always, is to think. What small step do we want to take next? For this episode, we look at the way we’re hiding tab content and how to better decouple our JavaScript and HTML.

Recent Advanced Episodes

Updates Monday and Wednesday

  1. Subsetting Karma

    Mon, 30 Nov ’15

    Now that we have a separate content directory, we want our CSS tests to run separately from the rest of our tests too. This will allow us to have faster incremental builds. We move our CSS tests into the content directory, then look at the question of getting Karma to run a subset of tests.

  2. Directory Refactoring: Solved!

    Wed, 25 Nov ’15

    We return to the directory refactoring problem that gave us so much trouble in the last episode. This time, we take smaller, more careful steps... and this time, everything goes smoothly. We’ve successfully separated our content from our code.

  3. The Challenges of Directory Refactoring

    Mon, 23 Nov ’15

    We’ve decided to refactor our directory structure, but this isn’t as easy as it sounds. It’s deeply intertwined with our build system, require() statements, and <script> includes. In this episode, we attempt to unwind the dependencies. We take small steps and make good progress... until we take a step that’s a bit too big.

An in-depth screencast about
Test-Driven JavaScript

You've taught me a lot this past year and have
been better than a teacher, a true mentor.
Jason Weden
I’m completely new to TDD and this is by far
the most comprehensive TDD for JS... your videos are
a breath of fresh air!
Adam Brodzinski
This is a gold mine... This will help a lot in my day job.
Timothy Myers
Love what you're doing. It's helped out our
team tremendously here at Sevenly.
Scott Corgan
I’m delighted with LCJ. It’s interesting and informative, and the
candid way you think aloud makes it personal and engaging.
You’ve done a terrific job.
Crispin Bennett

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 butt 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 15 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 test against multiple browsers and platforms, including iOS, and we use Node.js on the server.

All videos are DRM-free, available for streaming or download, and all source code is included.

The Videos

The series consists of four main channels. The “Recorded Live” channel focuses on real-world development, warts and all. It’s meant for experienced programmers.

If you’re a new developer, the “How To” channel is for you. It’s meant for beginners who have recently learned to program and are ready to start their professional career.

The “Lessons Learned” channel provides concise reviews of key topics, such as continuous integration, test-driven development, and build automation. It’s great for review and reference.

Advanced programmers will enjoy “The Lab”, our channel focused on exploring new tools and ideas.

Release Schedule

New videos are published every week. At the time of this writing, a new “Recorded Live” episode is released every Monday and Wednesday, and a new “How To” episode is released every Friday.

When the current “How To” season finishes, we will probably return releasing a new “Lessons Learned” or “The Lab” episode on the first Friday of every month.

“Recorded Live” and “How To” episodes are about 15 minutes long. “Lessons Learned” videos are typically about 15-30 minutes long, and episodes of “The Lab” tend to be about an hour.

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.