SXSW 2015: Testing JavaScript Applications

Daniel Johnson
Software Architect

Presentation Description

So you’ve finally taken the advice of your peers and started writing unit tests for your JavaScript. Now what happens when you write great tests, but then realize the application’s features still don’t work right? Or you increase the code coverage, but still don’t get the quality your users expect. How much time is spent by your QA team running the same regression tests over and over again? Does the idea of performing a manual smoke test before each code commit make you want to run for the hills? All of these issues can be addressed with a better JavaScript testing approach.

Unit and functional tests are very closely tied to agile and behavior driven development (BDD) and this workshop will walk you through how to integrate testing best practices for a more reliable development process. It will also cover the various technologies used today such as Jasmine, PhantomJS, Selenium, and Cucumber to name a few, and how to integrate these into modern JavaScript applications.

The workshop will begin with an introduction to testing and why it’s so important in modern JavaScript development. We will then move into specific technologies used for testing as well as approaches for writing tests in popular JavaScript frameworks.

This workshop will include some hands on coding to introduce topics as well as demos and code samples that can be used in your own projects.

By the end of this four hour long workshop you’ll have learned:

  • What is testing and why is it so important for JavaScript
  • How does testing fit into Agile and BDD workflows
  • What are the most useful technologies for setting up and executing tests
  • Some approaches for writing tests in popular JavaScript frameworks (i.e. Backbone, Angular, React, etc.)
  • Hands on practice writing your own tests

Presentation Notes

Unit Tests

  • Test a small single unit of code
  • Run in isolation
    • If other pieces are needed, they are mocked
    • Used for code coverage metrics
  • Write unit tests for Business logic (validation, math, algorithms)
    • eg: the Model
  • Be cautious of any unit tests that requires mocking the DOM. You’ll just end up rewriting the entire application to mock the HTML.

Integration Tests

  • Test that multiple units of a system work together
  • Can be anything from a couple functions, to something that requires a resource like a database, to a full system wide test.
  • Write integration tests for critical features and paths through your app (eg: login)
    • eg: the View
  • These most commonly fall into the functional and acceptance testing category
  • It’s too expensive and not feasible to test every single user flow

You hook these into a git repo, and then you set it up so when you push to a repo it will go through a build process, and then deploy it.

Trying to do TDD/BDD in JavaScript (where you write test cases before starting) is harder than it is in Rails, Java, or some other languages.

Features and Scenarios

  • Feature:
    • Shopper can add an item to the Grocery List.
    • As a grocery shopper
    • I want to add an item to my grocery list
    • So that I can remember to buy that item at the grocery store
  • Scenario
    • Item added to grocery list
    • Given I have an empty grocery list
    • When I add an item to the list
    • Then the grocery list contains a single item
  • Scenario
    • Item accessible from grocery list
    • Given I have an empty grocery list
    • When I add an item to the list
    • Then I can access that item from the grocery list

Tools and Libraries

How to Choose?

No framework? No worries, use whatever combination you want.


  • Mocha (Displays results in terminal)
    • mathHelpers
    • Car
      • mocha –reporter spec –timeout 5000
        • –reporter spec: the way the test results are displayed
        • –timeout 5000: without this, async code may not be done executing (think AJAX)
  • Jasmine (Very similar to Mocha, displays results in HTML/browser)
    • mathHelpers
    • Car
    • HTTP (spyOn, http.get)
      • .toHaveBeenCalled() will tell us if any function has been called
      • .not.toHaveBeenCalled() will tell us if any function has NOT been called
      • toHaveBeenCalledWith() checks the parameters too
    • Blanket.js: a plugin that highlights what blocks your test coverages do not cover.
Posted in SXSW 2015.

Leave a Reply

Your email address will not be published. Required fields are marked *