Testing Service Workers

Matt Gaunt
Mar 6, 2017 · 18 min read

Types of Testing

There are a two ways to approach this topic of testing service workers. We could look at testing specific features or use-cases, for example testing a web app works offline. The alternative is to look at some of the methodologies for testing service workers, for example looking at how we write a unit test in a service worker environment, regardless of what that unit test is testing.

  1. Service Worker Units Tests
  2. Integration Tests
  3. Mock Environments

Tooling

Throughout this post I’ll be using MochaJS, this is by no-means a requirement for testing service workers, nor is this a suggestion that this is the best tool for the job, but it’s easy to comprehend and you should be able to apply the techniques used with MochaJS to your prefered test runner, if you can’t . . . . maybe try Mocha.

Browser Unit Tests

Mocha JS has support for writing tests in the browser, you’d typically create a HTML page, add script tags for mocha itself as well as script tags for your test files. Create a new html file and save it under ‘/test/browser/index.html’ in your project.

Super exciting huh?

Unit Tests in Service Worker

Mocha’s API is happy working in a normal JavaScript worker so it’s easy enough to get it working in a service worker.

  1. Send a message to the service worker to initiate the tests in the service worker.
  2. Wait for message from the service worker with test results
  3. Pass or fail the test in the window.
  • We have unit tests that register and tests some behaviours of service workers as a by-product.
  • We have unit tests running directly in a service worker context.

Emulating Service Worker Events

From within a service worker you can dispatch fake events by simply constructing a new event and dispatching it.

A Note of Test Structure

We’ve seen that with emulated events we can write tests that will run through what a browser would do in a service worker, but there are a few things to highlight.

Real Service Worker Events

If you’ve worked with service workers for caching and responding to fetch events, the fake events can feel inadequate and / or unnatural compared to how the service worker is actually used by the browser.

Real Fetch Events

First let’s look at how to test fetch events in a manner that includes the full browser behavior of using the service worker as a proxy for network requests.

Service Worker Scope 101

When you register a service worker, it is given a “scope” which be default is the location of the service worker. The scope restricts which pages are controlled by a service worker.

Real Fetch Events + Zombie Service Workers

What does “scope” have to do with testing fetch events?

  1. Add an iframe to the page.
  2. Set the iframe’s src to the scope from step 1 (i.e. iframe.src = ‘/test/iframe/<Timestamp>’).
  3. In your unit test, get a reference to the iframe in your JavaScript and use `iframeElement.contentWindow.fetch()`. This will make network requests through the iframe’s page, which will be controlled by the service worker, meaning your request will go through the service worker.
  4. After each test remove any iframes that were created and unregister any service workers.

Real Push Events

We’ve seen how fetch events can be tested with a scoping and iframe dance.

Mock Service Workers

The last thing topic to discuss is arguably the easiest approach for testing, mock out the service worker API’s and test on node.

Closing Remarks

A lot of the challenges you will face in testing initially is setting up the testing environment. Hopefully this will be less relevant over time through the use of mocks and test runners evolving to support unit tests in multiple environments without needing configuration from consumers of the tools.

Dev Channel

Developers Channel - the thoughts, opinions and musings from members of the Chrome team.

Matt Gaunt

Written by

(a.k.a Gaunt Face) @ Google

Dev Channel

Developers Channel - the thoughts, opinions and musings from members of the Chrome team.