Repository navigation
Refactor the WPT test runner to be a python test runner configuration #51854
Description
Activity
cc @panva @legendecas based on git log of
test/common/wpt.jsI'm just worried even less people will be able to make heads or tails of what it is doing. I for one would not be able to contribute anymore.
I personally find the Python runner easier to extend than the current WPT runner (and I wrote the initial implementation of the JS WPT runner - in retrospect I would've just do the harness in a preloaded script, instead of inventing a different runner, had I know that the WPT can start flaking). It's actually surprisingly simple, ignoring language differences.
Reacted by Moshe AtlowAlso, the harness part would still be in JS as a preloaded fixture, only the runner part would be in Python (I think most of the runner code in common/wpt.js is already reinventing what the python runner is capable of anyway...).
Reacted by Filip Skokan and Chengzhong WuI agree that the current WPT runner is trying to reinvent the capability of python runner but there are unique features like generating wpt.fyi reports. But I believe it would be straightforward to re-implement it in python runner as well.
Happened to be talking about this during the WinterCG breakout session at Web engine hackfest and it seems there are interest from Deno to work on a common test runner for JS runtimes and upstream it to WPT. If that common test runner could handle the points mentioned here that would be great and we would not need to maintain (alone) yet another test runner / adaptor for WPT (it was proposed mostly because of point 3, trying not to re-invent the wheel of conditional test running based on a status file, and the python test runner looks like a good target to piggy-back. But if there's something else that includes the wheel and another party helps maintain it, that sounds like a better piggy-backing target)
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.- added a commit that references this issue
on Aug 23, 2026 - added a commit that references this issue
on Aug 26, 2026 - added 2 commits that reference this issue
on Aug 29, 2026 A few updates since this was opened:
.cjsWPT status files have been supported since test,crypto: update WebCryptoAPI WPT #54593. These allow platform- and build-dependent conditions while retaining named subtest expectations.- test: support inspecting WPTs in child processes #65510 added inspector support through
WPT_INSPECT. It runs a selected non-worker WPT variant in a child process with--inspect-brk. - test: schedule WPT variants individually #65984 moves scheduling of generated WPT paths into the Python runner's work queue.
-jthen controls WPT concurrency, and individual paths get their own timings, failures, and reruns.
#65984 is marked to close this issue when it lands.
- added a commit that references this issue
on Sep 13, 2026 - added 2 commits that reference this issue
on Sep 15, 2026
While working on the flakes I noticed that there are still some drawbacks with the current WPT test runner (common/wpt.js):
out/Release/node --inspect-brk -r test/common/wpt-fixture.js test/fixtures/wpt/...and connect to the inspector server with a client.--workerswitch)