Skip to content

Testing

Jeffrey Posnick edited this page May 2, 2018 · 3 revisions

Testing in Workbox

Workbox is using a number of different tools to test the project and this document aims to outline the rough structure / flow for testing this repo.

To start with, it's worth calling out that each package is responsible for it's own tests. Looking under ./test/<Package Name>/ you'll find the tests for that package.

To run all tests you need to run:

gulp test

To run the tests for a specific package run:

gulp test --package="workbox-something-something"

Types of Tests

There are node tests and there are integration tests. Node tests will run in the mock environment and integration tests are free to do what ever they want.

You can run a specific type of test like so:

gulp test-node
gulp test-integration

Tools Used

The test runner used in this project is Mocha and we mock + stub the browser and service worker API's needed.

Individual tests will pull in any additional files they need, for example, chai for assertions and sinon for mocking.

Selenium Webdriver + Saucelabs

selenium-assistant is used to orchestrate the browser testing (this is a thin wrapper on top of selenium-webdriver).

We can also use Saucelabs to support browser testing on Windows and may be used for testing browsers that can be easily tested locally or across platforms.

Local Testing

If you want to manually check the available end points or behavior in the browser outside of a webdriver controller browser you can start a local test server like so:

gulp test-server

Special Test Serve Endpoint

One of the nice things about the test server (which is used to load the browser and service worker tests) is that they have a set of special endpoints (which are prefixed with two underscores '__').

  • /\/__WORKBOX\/buildFile\/(workbox-[A-z]*)(\.(?:dev|prod)\.(.*))*/

    This will serve a copy of the locally built module file. For example /__WORKBOX/buildFile/workbox-precaching.dev.js.