commit | ea2a5d683d75e38809bbe9ec5fb238267054b747 | [log] [tgz] |
---|---|---|
author | Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> | Thu Oct 26 21:23:32 2023 |
committer | GitHub <noreply@github.com> | Thu Oct 26 21:23:32 2023 |
tree | 28d52fa808256d42816ce7c3687944d5b5875747 | |
parent | 873c5ae303c06c2926278914faaf1e5329426424 [diff] |
sensors: Convert existing Generic Sensor web tests to test_driver (#41410) All Generic Sensor web tests are now using virtual sensors and their implementation in WPT's testdriver.js and ChromeDriver/content_shell. These tests no longer depend on generic_sensor_mocks.js (or Mojo mocks in general), which has been kept only for the Device Orientation tests at this point, and should be fully interoperable now. This also exercises the code in //content and //services. Compared to the JS mocks-based implementation, one of the biggest changes is that there is no equivalent to a MockSensor that takes an array of readings and periodically rotates and reports them to consumers. This was an implementation detail that was kind of hard to justify in spec terms, and the interaction between the JS timer and the C++ code in services could lead to races between shared buffer values and expected values (bug 1073865 is probably related, for example). We now follow the new Automation section in the Generic Sensor spec and explicitly require reading updates to be done via calls to test_driver.update_virtual_sensor(). These calls might not result in a change in readings if the sensor is not active or if the threshold/rounding checks fail, so the tests are careful to check that a reading has gone through when necessary. Furthermore, given how the code in //services is implemented it is not possible to assert that a call to update_virtual_sensor() will resolve _before_ a "reading" event is emitted, so some Promise.all() calls are required. The iframe tests have been essentially rewritten for clarity and to test the right things: * iframe_sensor_handler.html is used only by the cross-origin test. The same-origin one simply creates the sensor in the test file directly. * send_message_to_iframe() does not take a |reply| argument anymore. Instead, it propagate the replies to the callers so they can do whatever they need and we do not need to come up with values like "success" in replies. * The cross-origin and same-origin tests follow a workflow that is easier to follow and mostly relies on timestamps that are part of the public API to determine whether readings are being provided or not depending on frame focus. Now that the //content code is being exercised, the Ambient Light Sensor and Magnetometer web tests need the GenericSensorExtraClasses feature to be enabled, which is done by the newly-created generic-sensor-extra-classes virtual test suite. Finally, the referenceFrame test in generic-sensor-tests.js has been disabled and a copy was added to wpt_internal, as there is no cross-platform way to set an orientation angle and in wpt_internal it can be set via Internals' setMockScreenOrientation(). Bug: 1278377, 1471996 Change-Id: Ie556c6d7bcfc0b2b84abc5f0770f6b3120ec81a2 Co-authored-by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
The web-platform-tests Project is a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software that is compatible with other implementations, and that later implementations will be compatible with their implementations. This in turn gives Web authors/developers confidence that they can actually rely on the Web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps left by specification editors and implementors.
The most important sources of information and activity are:
wpt:matrix.org
matrix channel; includes participants located around the world, but busiest during the European working day.If you'd like clarification about anything, don't hesitate to ask in the chat room or on the mailing list.
Clone or otherwise get https://github.com/web-platform-tests/wpt.
Note: because of the frequent creation and deletion of branches in this repo, it is recommended to “prune” stale branches when fetching updates, i.e. use git pull --prune
(or git fetch -p && git merge
).
See the documentation website and in particular the system setup for running tests locally.
The wpt
command provides a frontend to a variety of tools for working with and running web-platform-tests. Some of the most useful commands are:
wpt serve
- For starting the wpt http serverwpt run
- For running tests in a browserwpt lint
- For running the lint against all testswpt manifest
- For updating or generating a MANIFEST.json
test manifestwpt install
- For installing the latest release of a browser or webdriver server on the local machine.wpt serve-wave
- For starting the wpt http server and the WAVE test runner. For more details on how to use the WAVE test runner see the documentation.On Windows wpt
commands must be prefixed with python
or the path to the python binary (if python
is not in your %PATH%
).
python wpt [command]
Alternatively, you may also use Bash on Ubuntu on Windows in the Windows 10 Anniversary Update build, then access your windows partition from there to launch wpt
commands.
Please make sure git and your text editor do not automatically convert line endings, as it will cause lint errors. For git, please set git config core.autocrlf false
in your working tree.
The master branch is automatically synced to wpt.live and w3c-test.org.
Save the Web, Write Some Tests!
Absolutely everyone is welcome to contribute to test development. No test is too small or too simple, especially if it corresponds to something for which you've noted an interoperability bug in a browser.
The way to contribute is just as usual:
git checkout -b topic
../wpt lint
as described above.If you spot an issue with a test and are not comfortable providing a pull request per above to fix it, please file a new issue. Thank you!