Worker WPT tests
These are the workers (Worker, SharedWorker) tests for the
Web workers chapter of the HTML Standard.
See also testharness.js API > Web Workers.
Writing *.any.js
The easiest and most recommended way to write tests for workers is to create .any.js-style tests.
Official doc: WPT > File Name Flags > Test Features.
- Standard
testharness.js-style can be used (and is enforced). - The same test can be run on window and many types of workers.
- All glue code are automatically generated.
- No need to care about how to create and communicate with each type of workers,
thanks to
fetch_tests_from_workerintestharness.js.
Converting existing tests into .any.js-style also has benefits:
- Multiple tests can be merged into one.
- Tests written for window can be run on workers with a very low development cost.
How to write tests
If you write testharness.js-based tests in foo.any.js and
specify types of workers to be tested,
the test can run on any of dedicated, shared and service workers.
See examples/general.any.js for example.
Even for testing specific features in a specific type of workers
(e.g. shared worker's onconnect), .any.js-style tests can be used.
See examples/onconnect.any.js for example.
How to debug tests
Whether each individual test passed or failed, and its assertion failures (if any) are all reported in the final results.
console.log() might not appear in the test results and
thus might not be useful for printf debugging.
For example, in Chromium, this message
- Appears (in stderr) on a window or a dedicated worker, but
- Does NOT appear on a shared worker or a service worker.
How it works
.any.js-style tests use
fetch_tests_from_worker functionality of testharness.js.
The WPT test server generates necessary glue code (including generated Document HTML and worker top-level scripts). See serve.py for the actual glue code.
Note that .any.js file is not the worker top-level script,
and currently we cannot set response headers to the worker top-level script,
e.g. to set Referrer Policy of the workers.
Writing *.worker.js
Similar to .any.js, you can also write .worker.js
for tests only for dedicated workers.
Almost the same as .any.js, except for the things listed below.
Official doc: WPT > File Name Flags > Test Features.
How to write tests
You have to write two things manually (which is generated in .any.js tests):
importScripts("/resources/testharness.js");at the beginning.done();at the bottom.
Note: Even if you write async_test() or promise_test(),
this global done() is always needed
(this is different from async_test's done())
for dedicated workers and shared workers.
See official doc:
testharness.js API > Determining when all tests are complete.
See examples/general.worker.js for example.
How it works
.worker.js-style tests also use
fetch_tests_from_worker functionality of testharness.js.
The WPT test server generates glue code in Document HTML-side,
but not for worker top-level scripts.
This is why you have to manually write importScripts() etc.
See
serve.py
for the actual glue code.
Unlike *.any.js cases, the *.worker.js is the worker top-level script.
Using fetch_tests_from_worker
If you need more flexibility,
writing tests using fetch_tests_from_worker is the way to go.
For example, when
- Additional processing is needed on the parent Document.
- Workers should be created in a specific way.
- You are writing non-WPT tests using
testharness.js.
You have to write the main HTMLs and the worker scripts,
but most of the glue code needed for running tests on workers
are provided by fetch_tests_from_worker.
How to write tests
See
examples/fetch_tests_from_worker.htmlandexamples/fetch_tests_from_worker.js.
Writing the whole tests manually
If fetch_tests_from_worker isn't suitable for your specific case
(which should be rare but might be still possible),
you have to write the whole tests,
including the main Document HTML, worker scripts,
and message passing code between them.
TODO: Supply the templates for writing this kind of tests.