This directory contains tests for the Compute Pressure specification.
How to write tests
Tests that only need to run on a window
To test this API, one needs to be able to control the pressure data that will be reported to script. At a high level, this is done by calling certain WebDriver endpoints via their corresponding testdriver wrappers.
Tests that need to run on windows and dedicated workers
Certain testdriver limitations require calls to be made from the top-level test context, which effectively prevents us from simply running the same test from multiple globals with any.js.
What we do instead is write all tests for the Window
global,
use
variants
for specifying different globals and using the pressure_test()
and
mark_as_done()
helpers.
In short, the boilerplate for a new test foo.https.window.js
looks like this:
// META: variant=?globalScope=window
// META: variant=?globalScope=dedicated_worker
// META: script=/resources/testdriver.js
// META: script=/resources/testdriver-vendor.js
// META: script=/common/utils.js
// META: script=/common/dispatcher/dispatcher.js
// META: script=./resources/common.js
pressure_test(async t => {
}, 'my test');
mark_as_done();
- The variants specify which global context the tests should run on. The only
two options are
window
anddedicated_worker
. - We need to include all those scripts for the testdriver and RemoteContext infrastructure to work.
pressure_test()
is a wrapper around apromise_test()
that takes care of running the test either in the current context (whenglobalScope=window
) or in a dedicated worker viaRemoteContext
andfetch_tests_from_worker()
(whenglobalScope=dedicated_worker
).mark_as_done()
is a no-op whenglobalScope=window
, but is necessary whenglobalScope=dedicated_worker
to ensure that all tests have run and thatdone()
is called in the worker context.
Shared workers
Since custom pressure states are stored in a top-level navigables, they are currently not integrated with shared workers (see spec issue 285) and support for testing shared workers is limited.