- From: Matt Giuca <mgiuca@chromium.org>
- Date: Fri, 10 Mar 2017 04:04:56 +0000
- To: Giovanni Ortuño <ortuno@chromium.org>, public-test-infra@w3.org
- Cc: Philip Jägenstedt <foolip@chromium.org>, "Vincent Scheib (via Google Docs)" <scheib@chromium.org>, Jeffrey Yasskin <jyasskin@chromium.org>, Reilly Grant <reillyg@chromium.org>
- Message-ID: <CAHqYdcY9ZczHNU3kYCkR0Cn5huk-B22Y4CTmG+KS0pqwRLhZ8g@mail.gmail.com>
I love this approach! Thanks for sharing and the write-up, Gio. > On the main repo that file would be empty but on the Chromium repo that file would have the necessary code to fake devices in Chromium. s/empty/stubs? I would definitely be up for converting my navigator.share <https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/webshare/share-success.html> and navigator.getInstalledRelatedApps <https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/installedapp/getinstalledrelatedapps.html> layout tests (which currently use an explicit mock of calls to the Mojo service) to a standard fake interface. Since my APIs are significantly simpler than Bluetooth, I might give it a shot and report back to this group. (Note though that they aren't standardised yet so I'm not sure if they'd be includeable in TestHarness. Still would serve as a useful case study.) On Fri, 10 Mar 2017 at 14:52 Giovanni Ortuño <ortuno@chromium.org> wrote: Hi all, Some context: We, the Web Bluetooth team, are looking into upstreaming our Chromium Layout Tests to Web Platform Tests. In order to test the Web Bluetooth API, we are introducing a Test API that accompanies the spec and allows our tests to fake Bluetooth Devices: Web Bluetooth Test <https://docs.google.com/document/d/1Nhv_oVDCodd1pEH_jj9k8gF4rPGb_84VYaZ9IG8M_WY/edit#heading=h.ap8dnjfog4qc> .. Parts of this API are implemented in JS. These parts are Chromium specific, e.g. how to talk with our IPC system, so it wouldn't make sense to include them as resources. To that extent, we would like to add a file called "web-bluetooth-test.js" which would be similar to "testharnessreport.js" to the testharness repo. On the main repo that file would be empty but on the Chromium repo that file would have the necessary code to fake devices in Chromium. There are many APIs that follow a similar pattern: they define a Test API surface that they use to fake behavior. Some examples include Geolocation <https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/geolocation-api/error.html?type=cs&q=mojo-helpers+file:%5Esrc/third_party/WebKit/LayoutTests/geolocation-api/+package:%5Echromium$&l=17>, Vibration <https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/vibration/vibration-durations.html?l=13>, NFC <https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/nfc/push.html?l=73>, Sensors <https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/sensor/accelerometer.html?l=45>, etc. So we think it would make sense to add a folder to include all of these Test APIs in, straw-man proposal: platform-fakes. ../ ../testharness.js ../testharnessreport.js ../platform-fakes/web-bluetooth-test.js ../platform-fakes/geolocation-test.js .... Do y'all think this is a good approach? Let me know what you think, Gio
Received on Friday, 10 March 2017 04:06:34 UTC