Having worked for both Playstation and Pinterest, both with huge numbers of users, there is nothing that scares me more than pushing code with zero tests. I mean, I know I’m good, but my bugs disagree.
As I started looking into service workers, I was really excited about the potential. Faster asset caching, offline mode, and the ability to finally have mobile web feel native_._ The more I learned, the more I realized that there was no easy way to test service workers, which was scary. A service worker caching bug can cripple your site in an almost invisible way. Best to be careful.
Shout out to Matt Gaunt for writing Testing Service Workers. The answer to testing service workers was: there is no easy way, but here’s how you CAN. I didn’t like that answer.
So I built a thing. Service Worker Mock.
The idea is that you can write your tests as if the tests themselves were being executed within a service worker environment. That means that you can require your service worker script, and make assertions against the contents of your cache, the registered listeners, and visible notifications. Super easy, and open-source. Let’s look at how it works.
For each test, we transform the current global context into a service-worker environment. That means that when you require your service worker, variables like self and addEventListener will be available to your script. Notice the jest.resetModules(); this is important so that when you require your service worker multiple times in your tests it actually executes the script each time. If you’re not using jest, you should be able to clear the require.cache.
Now let’s write our first test! The following tests are based off of Google’s basic service worker example. Here we want to test that when ‘activate’ is fired, it clears out old caches.
Using service-worker-mock this is trivial. All we need to do is execute the service worker (which will add our event listeners), open a cache, and fire the ‘activate’ event. We can use the ServiceWorkerMock global ‘snapshot’ function to check the current contents of the cache. It really doesn’t get much simpler than that.
So what about fetch? That is the bread and butter of service workers. Caching responses and deciding our strategy for using the cached data for future requests. Testing this is really hard without service-worker-mock. Let’s see what it looks like using the helpers.
First we put a response in the cache, then trigger a fetch request. The response should exactly equal the response that we put in the cache. Easy peasy! You’ll want to mock out the fetch method as well, to test when you don’t get a cached response.
Overall, I’m pretty happy with how the mock environment turned out. Let’s start writing more tests for service workers!
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!