Add support for testing the WebExtensions API in WPT #219
Conversation
This RFC documents our proposal for adding support for testing the WebExtensions API in the web platform tests.
| This RFC proposes adding a new `testharness.js` test type, `.extension.js`, to handle | ||
| testing this API, in addition to using `testdriver.js` to load and unload extensions. |
There was a problem hiding this comment.
This technically isn't a new test type (because the manifest will still make it a testharness test), it's just server-side support for creating them from a pure JS file.
We could potentially split this out into a separate RFC, but that's probably only worthwhile if we start having significant debates about whether/what that support should be.
| The extension will be loaded after the tests begins, and unloaded before the | ||
| test is finished. |
There was a problem hiding this comment.
We probably don't need this; technically people writing tests can do whatever, and I don't think we need to justify this.
I'd probably add:
Per RFC 127, with it being specified for both WebDriver Classic and WebDriver BiDi, this is inherently acceptable.
| The extension will be loaded after the tests begins, and unloaded before the | ||
| test is finished. | ||
|
|
||
| Most of the test execution is handled within the extension, via the |
There was a problem hiding this comment.
I think we need a sentence preceding this, maybe the one from the following paragraph?
These tests won't leverage
testharness.jsdirectly as…
| [browser.test](https://chromium.googlesource.com/chromium/src.git/+/master/extensions/docs/testing_api.md) | ||
| API. We’ve elected to use these APIs since all participating browser vendors use | ||
| `browser.test` internally and they can easily port over existing tests to | ||
| the web platform tests. |
There was a problem hiding this comment.
| the web platform tests. | |
| web-platform-tests. |
| Because these tests won’t leverage `testharness.js` directly, we’ve introduced a new | ||
| `testharness.js`, `.extension.js`, that will create the necessary boilerplate to | ||
| convert the `browser.test` assertions into the corresponding assertions in the test | ||
| harness. |
There was a problem hiding this comment.
We should probably care to some extent about how easy/difficult it is to write tests without using extension.js.
Rather than putting all the code necessary to map from browser.test to testharness.js in the server-generated wrapper, it would probably be better to put it into a separate file — which then gets included (along with testharness and testdriver) by the server-generated wrapper?
No description provided.