856275f602
Automatic update from web-platform-tests compute pressure: Increase timeouts and drop uses of t.step_wait() - When we need to wait to verify that an update was _not_ sent, update the timeout from 1 second to 3 seconds (and mark tests with timeout=long). 1 second is sometimes too little for busy bots such as the mac-rel and win-rel ones, which can lead to flakiness or, in this case, updates not being delivered for the wrong reason (i.e. the browser process just has not had time to process the update_virtual_pressure_source() call). - Introduce a new SyncPressureObserver wrapper class that stores multiple pressure updates and allows users to synchronously wait for the next one using Promises. This is useful for tests that need to send and wait for multiple updates: instead of polling using t.step_wait(), these tests can just use this class to wait for a Promise to resolve when an update is delivered. Bug: 347031400 Change-Id: I7880577757d71678e612d912716f4f12020a5fef Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5912856 Reviewed-by: Reilly Grant <reillyg@chromium.org> Commit-Queue: Reilly Grant <reillyg@chromium.org> Auto-Submit: Raphael Kubo Da Costa <raphael.kubo.da.costa@intel.com> Cr-Commit-Position: refs/heads/main@{#1365092} -- wpt-commits: 5f9ff498baa353f2666c42fe3662f67b7e1e806f wpt-pr: 48503
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
windowanddedicated_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 viaRemoteContextandfetch_tests_from_worker()(whenglobalScope=dedicated_worker).mark_as_done()is a no-op whenglobalScope=window, but is necessary whenglobalScope=dedicated_workerto 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.