Phil Leggetter: Testing Ginormous JavaScript applications

Orde Saunders' avatarPublished: by Orde Saunders

Phil Leggetter (@leggetter) was talking about testing ginormous JavaScript applications at Scotland.js, these are my notes from his talk.

The more functionality you have the more code you have - you have to deal with that.

Massive part of this is testing.  Class level unit tests and application acceptance test.  Code facing tests vs business facing tests.  Took place on VMs - browser VM + back end VM which had to be paired.  ~500 acceptance tests running on 50 VM pairs - took 8 hours to run :-(  Could only run overnight so had some smoke tests that ran quickly but they weren't reliable.


  • Need to restart the browser each time to get a clean state - can introduce a 10s delay.  Multiply that by number of tests and number of browsers you are testing.
  • Need to restart the back end servers to get a clean state - this took time and wasn't reliable causing tests to fail becuse of the environment not the code.
  • Don't touch the DOM - tests might fail because of the DOM rather than the code.  Also can't change UI without changing tests.


  • Split your app into components/modules/features/blades
  • Each component has its own assets (JS, HTML, CSS, tests)
  • Can run each component in isolation - forces isolation.
  • Only provide back end services required for each component.
  • Have a service registry which can be used to insert mocks for services.

End result is that everything only runs in JS in the browser.

Use the view model to test UI interactions - we trust the UI->DOM layer to do its job.

Tests went from 8 hours on a server farm of VMs to 30 minutes on a single machine.

Key points

  1. Components
  2. Service layer
  3. MVVM - Don't touch the DOM

Comments, suggestions, corrections? Contact me via this website