diff options
Diffstat (limited to 'testing/web-platform/tests/resources/docs')
| -rw-r--r-- | testing/web-platform/tests/resources/docs/api.md | 704 | ||||
| -rw-r--r-- | testing/web-platform/tests/resources/docs/idlharness.md | 128 |
2 files changed, 832 insertions, 0 deletions
diff --git a/testing/web-platform/tests/resources/docs/api.md b/testing/web-platform/tests/resources/docs/api.md new file mode 100644 index 000000000..980f4246c --- /dev/null +++ b/testing/web-platform/tests/resources/docs/api.md @@ -0,0 +1,704 @@ +## Introduction ## + +testharness.js provides a framework for writing testcases. It is intended to +provide a convenient API for making common assertions, and to work both +for testing synchronous and asynchronous DOM features in a way that +promotes clear, robust, tests. + +## Basic Usage ## + +The test harness script can be used from HTML or SVG documents and web worker +scripts. + +From an HTML or SVG document, start by importing both `testharness.js` and +`testharnessreport.js` scripts into the document: + +```html +<script src="/resources/testharness.js"></script> +<script src="/resources/testharnessreport.js"></script> +``` + +Refer to the [Web Workers](#web-workers) section for details and an example on +testing within a web worker. + +Within each file one may define one or more tests. Each test is atomic in the +sense that a single test has a single result (`PASS`/`FAIL`/`TIMEOUT`/`NOTRUN`). +Within each test one may have a number of asserts. The test fails at the first +failing assert, and the remainder of the test is (typically) not run. + +If the file containing the tests is a HTML file, a table containing the test +results will be added to the document after all tests have run. By default this +will be added to a `div` element with `id=log` if it exists, or a new `div` +element appended to `document.body` if it does not. + +NOTE: By default tests must be created before the load event fires. For ways +to create tests after the load event, see "Determining when all tests +are complete", below. + +## Synchronous Tests ## + +To create a synchronous test use the `test()` function: + +```js +test(test_function, name, properties) +``` + +`test_function` is a function that contains the code to test. For example a +trivial test for the DOM +[`hasFeature()`](https://dom.spec.whatwg.org/#dom-domimplementation-hasfeature) +method (which is defined to always return true) would be: + +```js +test(function() { + assert_true(document.implementation.hasFeature()); +}, "hasFeature() with no arguments") +``` + +The function passed in is run in the `test()` call. + +`properties` is a javascript object for passing extra options to the +test. Currently it is only used to provide test-specific +metadata, as described in the [metadata](#metadata) section below. + +## Asynchronous Tests ## + +Testing asynchronous features is somewhat more complex since the result of +a test may depend on one or more events or other callbacks. The API provided +for testing these features is intended to be rather low-level but hopefully +applicable to many situations. + +To create a test, one starts by getting a `Test` object using `async_test`: + +```js +async_test(name, properties) +``` + +e.g. + +```js +var t = async_test("DOMContentLoaded") +``` + +Assertions can be added to the test by calling the step method of the test +object with a function containing the test assertions: + +```js +document.addEventListener("DOMContentLoaded", function() { + t.step(function() { + assert_true(e.bubbles, "bubbles should be true"); + }); +}); +``` + +When all the steps are complete, the `done()` method must be called: + +```js +t.done(); +``` + +As a convenience, `async_test` can also takes a function as first argument. +This function is called with the test object as both its `this` object and +first argument. The above example can be rewritten as: + +```js +async_test(function(t) { + document.addEventListener("DOMContentLoaded", function() { + t.step(function() { + assert_true(e.bubbles, "bubbles should be true"); + }); + t.done(); + }); +}, "DOMContentLoaded"); +``` + +which avoids cluttering the global scope with references to async +tests instances. + +The properties argument is identical to that for `test()`. + +In many cases it is convenient to run a step in response to an event or a +callback. A convenient method of doing this is through the `step_func` method +which returns a function that, when called runs a test step. For example + +```js +document.addEventListener("DOMContentLoaded", t.step_func(function() { + assert_true(e.bubbles, "bubbles should be true"); + t.done(); +}); +``` + +As a further convenience, the `step_func` that calls `done()` can instead +use `step_func_done`, as follows: + +```js +document.addEventListener("DOMContentLoaded", t.step_func_done(function() { + assert_true(e.bubbles, "bubbles should be true"); +}); +``` + +For asynchronous callbacks that should never execute, `unreached_func` can +be used. For example: + +```js +document.documentElement.addEventListener("DOMContentLoaded", + t.unreached_func("DOMContentLoaded should not be fired on the document element")); +``` + +Keep in mind that other tests could start executing before an Asynchronous +Test is finished. + +## Promise Tests ## + +`promise_test` can be used to test APIs that are based on Promises: + +```js +promise_test(test_function, name, properties) +``` + +`test_function` is a function that receives a test as an argument and returns a +promise. The test completes when the returned promise resolves. The test fails +if the returned promise rejects. + +E.g.: + +```js +function foo() { + return Promise.resolve("foo"); +} + +promise_test(function() { + return foo() + .then(function(result) { + assert_equals(result, "foo", "foo should return 'foo'"); + }); +}, "Simple example"); +``` + +In the example above, `foo()` returns a Promise that resolves with the string +"foo". The `test_function` passed into `promise_test` invokes `foo` and attaches +a resolve reaction that verifies the returned value. + +Note that in the promise chain constructed in `test_function` assertions don't +need to wrapped in `step` or `step_func` calls. + +Unlike Asynchronous Tests, Promise Tests don't start running until after the +previous Promise Test finishes. + +`promise_rejects` can be used to test Promises that need to reject: + +```js +promise_rejects(test_object, code, promise, description) +``` + +The `code` argument is equivalent to the same argument to the `assert_throws` +function. + +Here's an example where the `bar()` function returns a Promise that rejects +with a TypeError: + +```js +function bar() { + return Promise.reject(new TypeError()); +} + +promise_test(function(t) { + return promise_rejects(t, new TypeError(), bar()); +}, "Another example"); +``` + +`EventWatcher` is a constructor function that allows DOM events to be handled +using Promises, which can make it a lot easier to test a very specific series +of events, including ensuring that unexpected events are not fired at any point. + +Here's an example of how to use `EventWatcher`: + +```js +var t = async_test("Event order on animation start"); + +var animation = watchedNode.getAnimations()[0]; +var eventWatcher = new EventWatcher(watchedNode, ['animationstart', + 'animationiteration', + 'animationend']); + +eventWatcher.wait_for(t, 'animationstart').then(t.step_func(function() { + assertExpectedStateAtStartOfAnimation(); + animation.currentTime = END_TIME; // skip to end + // We expect two animationiteration events then an animationend event on + // skipping to the end of the animation. + return eventWatcher.wait_for(['animationiteration', + 'animationiteration', + 'animationend']); +})).then(t.step_func(function() { + assertExpectedStateAtEndOfAnimation(); + t.done(); +})); +``` + +`wait_for` either takes the name of a single event and returns a Promise that +will resolve after that event is fired at the watched node, or else it takes an +array of the names of a series of events and returns a Promise that will +resolve after that specific series of events has been fired at the watched node. + +`EventWatcher` will assert if an event occurs while there is no `wait_for`() +created Promise waiting to be fulfilled, or if the event is of a different type +to the type currently expected. This ensures that only the events that are +expected occur, in the correct order, and with the correct timing. + +## Single Page Tests ## + +Sometimes, particularly when dealing with asynchronous behaviour, +having exactly one test per page is desirable, and the overhead of +wrapping everything in functions for isolation becomes +burdensome. For these cases `testharness.js` support "single page +tests". + +In order for a test to be interpreted as a single page test, then +it must simply not call `test()` or `async_test()` anywhere on the page, and +must call the `done()` function to indicate that the test is complete. All +the `assert_*` functions are avaliable as normal, but are called without +the normal step function wrapper. For example: + +```html +<!doctype html> +<title>Basic document.body test</title> +<script src="/resources/testharness.js"></script> +<script src="/resources/testharnessreport.js"></script> +<body> + <script> + assert_equals(document.body, document.getElementsByTagName("body")[0]) + done() + </script> +``` + +The test title for single page tests is always taken from `document.title`. + +## Making assertions ## + +Functions for making assertions start `assert_`. The full list of +asserts avaliable is documented in the [asserts](#list-of-assertions) section +below. The general signature is + +```js +assert_something(actual, expected, description) +``` + +although not all assertions precisely match this pattern e.g. `assert_true` +only takes `actual` and `description` as arguments. + +The description parameter is used to present more useful error messages when +a test fails + +NOTE: All asserts must be located in a `test()` or a step of an +`async_test()`, unless the test is a single page test. Asserts outside +these places won't be detected correctly by the harness and may cause +unexpected exceptions that will lead to an error in the harness. + +## Cleanup ## + +Occasionally tests may create state that will persist beyond the test itself. +In order to ensure that tests are independent, such state should be cleaned +up once the test has a result. This can be achieved by adding cleanup +callbacks to the test. Such callbacks are registered using the `add_cleanup` +function on the test object. All registered callbacks will be run as soon as +the test result is known. For example + +```js + test(function() { + var element = document.createElement("div"); + element.setAttribute("id", "null"); + document.body.appendChild(element); + this.add_cleanup(function() { document.body.removeChild(element) }); + assert_equals(document.getElementById(null), element); + }, "Calling document.getElementById with a null argument."); +``` + +## Timeouts in Tests ## + +In general the use of timeouts in tests is discouraged because this is +an observed source of instability in real tests when run on CI +infrastructure. In particular if a test should fail when something +doesn't happen, it is good practice to simply let the test run to the +full timeout rather than trying to guess an appropriate shorter +timeout to use. + +In other cases it may be necessary to use a timeout (e.g., for a test +that only passes if some event is *not* fired). In this case it is +*not* permitted to use the standard `setTimeout` function. Instead one +must use the `step_timeout` function: + +```js +async_test(function(t) { + var gotEvent = false; + document.addEventListener("DOMContentLoaded", t.step_func(function() { + assert_false(gotEvent, "Unexpected DOMContentLoaded event"); + gotEvent = true; + t.step_timeout(function() { t.done(); }, 2000); + }); +}, "Only one DOMContentLoaded"); +``` + +The difference between `setTimeout` and `step_timeout` is that the +latter takes account of the timeout multiplier when computing the +delay; e.g., in the above case a timeout multiplier of 2 would cause a +pause of 4000ms before calling the callback. This makes it less likely +to produce unstable results in slow configurations. + +Note that timeouts generally need to be a few seconds long in order to +produce stable results in all test environments. + +For single-page tests, `step_timeout` is also available as a global +function. + +## Harness Timeout ## + +The overall harness admits two timeout values `"normal"` (the +default) and `"long"`, used for tests which have an unusually long +runtime. After the timeout is reached, the harness will stop +waiting for further async tests to complete. By default the +timeouts are set to 10s and 60s, respectively, but may be changed +when the test is run on hardware with different performance +characteristics to a common desktop computer. In order to opt-in +to the longer test timeout, the test must specify a meta element: + +```html +<meta name="timeout" content="long"> +``` + +Occasionally tests may have a race between the harness timing out and +a particular test failing; typically when the test waits for some event +that never occurs. In this case it is possible to use `test.force_timeout()` +in place of `assert_unreached()`, to immediately fail the test but with a +status of `TIMEOUT`. This should only be used as a last resort when it is +not possible to make the test reliable in some other way. + +## Setup ## + +Sometimes tests require non-trivial setup that may fail. For this purpose +there is a `setup()` function, that may be called with one or two arguments. +The two argument version is: + +```js +setup(func, properties) +``` + +The one argument versions may omit either argument. +func is a function to be run synchronously. `setup()` becomes a no-op once +any tests have returned results. Properties are global properties of the test +harness. Currently recognised properties are: + +`explicit_done` - Wait for an explicit call to done() before declaring all +tests complete (see below; implicitly true for single page tests) + +`output_document` - The document to which results should be logged. By default +this is the current document but could be an ancestor document in some cases +e.g. a SVG test loaded in an HTML wrapper + +`explicit_timeout` - disable file timeout; only stop waiting for results +when the `timeout()` function is called (typically for use when integrating +with some existing test framework that has its own timeout mechanism). + +`allow_uncaught_exception` - don't treat an uncaught exception as an error; +needed when e.g. testing the `window.onerror` handler. + +`timeout_multiplier` - Multiplier to apply to per-test timeouts. + +## Determining when all tests are complete ## + +By default the test harness will assume there are no more results to come +when: + + 1. There are no `Test` objects that have been created but not completed + 2. The load event on the document has fired + +This behaviour can be overridden by setting the `explicit_done` property to +true in a call to `setup()`. If `explicit_done` is true, the test harness will +not assume it is done until the global `done()` function is called. Once `done()` +is called, the two conditions above apply like normal. + +Dedicated and shared workers don't have an event that corresponds to the `load` +event in a document. Therefore these worker tests always behave as if the +`explicit_done` property is set to true. Service workers depend on the +[install](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#service-worker-global-scope-install-event) +event which is fired following the completion of [running the +worker](https://html.spec.whatwg.org/multipage/workers.html#run-a-worker). + +## Generating tests ## + +There are scenarios in which is is desirable to create a large number of +(synchronous) tests that are internally similar but vary in the parameters +used. To make this easier, the `generate_tests` function allows a single +function to be called with each set of parameters in a list: + +```js +generate_tests(test_function, parameter_lists, properties) +``` + +For example: + +```js +generate_tests(assert_equals, [ + ["Sum one and one", 1+1, 2], + ["Sum one and zero", 1+0, 1] + ]) +``` + +Is equivalent to: + +```js +test(function() {assert_equals(1+1, 2)}, "Sum one and one") +test(function() {assert_equals(1+0, 1)}, "Sum one and zero") +``` + +Note that the first item in each parameter list corresponds to the name of +the test. + +The properties argument is identical to that for `test()`. This may be a +single object (used for all generated tests) or an array. + +## Callback API ## + +The framework provides callbacks corresponding to 4 events: + + * `start` - triggered when the first Test is created + * `test_state` - triggered when a test state changes + * `result` - triggered when a test result is received + * `complete` - triggered when all results are received + +The page defining the tests may add callbacks for these events by calling +the following methods: + + `add_start_callback(callback)` - callback called with no arguments + + `add_test_state_callback(callback)` - callback called with a test argument + + `add_result_callback(callback)` - callback called with a test argument + + `add_completion_callback(callback)` - callback called with an array of tests + and an status object + +tests have the following properties: + + * `status` - A status code. This can be compared to the `PASS`, `FAIL`, + `TIMEOUT` and `NOTRUN` properties on the test object + + * `message` - A message indicating the reason for failure. In the future this + will always be a string + + The status object gives the overall status of the harness. It has the + following properties: + + * `status` - Can be compared to the `OK`, `ERROR` and `TIMEOUT` properties + + * `message` - An error message set when the status is `ERROR` + +## External API ## + +In order to collect the results of multiple pages containing tests, the test +harness will, when loaded in a nested browsing context, attempt to call +certain functions in each ancestor and opener browsing context: + + * start - `start_callback` + * test\_state - `test_state_callback` + * result - `result_callback` + * complete - `completion_callback` + +These are given the same arguments as the corresponding internal callbacks +described above. + +## External API through cross-document messaging ## + +Where supported, the test harness will also send messages using cross-document +messaging to each ancestor and opener browsing context. Since it uses the +wildcard keyword (\*), cross-origin communication is enabled and script on +different origins can collect the results. + +This API follows similar conventions as those described above only slightly +modified to accommodate message event API. Each message is sent by the harness +is passed a single vanilla object, available as the `data` property of the event +object. These objects are structures as follows: + + * start - `{ type: "start" }` + * test\_state - `{ type: "test_state", test: Test }` + * result - `{ type: "result", test: Test }` + * complete - `{ type: "complete", tests: [Test, ...], status: TestsStatus }` + +## Web Workers ## + +The `testharness.js` script can be used from within [dedicated workers, shared +workers](https://html.spec.whatwg.org/multipage/workers.html) and [service +workers](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/). + +Testing from a worker script is different from testing from an HTML document in +several ways: + +* Workers have no reporting capability since they are runing in the background. + Hence they rely on `testharness.js` running in a companion client HTML document + for reporting. + +* Shared and service workers do not have a unique client document since there + could be more than one document that communicates with these workers. So a + client document needs to explicitly connect to a worker and fetch test results + from it using `fetch_tests_from_worker`. This is true even for a dedicated + worker. Once connected, the individual tests running in the worker (or those + that have already run to completion) will be automatically reflected in the + client document. + +* The client document controls the timeout of the tests. All worker scripts act + as if they were started with the `explicit_timeout` option (see the [Harness + timeout](#harness-timeout) section). + +* Dedicated and shared workers don't have an equivalent of an `onload` event. + Thus the test harness has no way to know when all tests have completed (see + [Determining when all tests are + complete](#determining-when-all-tests-are-complete)). So these worker tests + behave as if they were started with the `explicit_done` option. Service + workers depend on the + [oninstall](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#service-worker-global-scope-install-event) + event and don't require an explicit `done` call. + +Here's an example that uses a dedicated worker. + +`worker.js`: + +```js +importScripts("/resources/testharness.js"); + +test(function(t) { + assert_true(true, "true is true"); +}, "Simple test"); + +// done() is needed because the testharness is running as if explicit_done +// was specified. +done(); +``` + +`test.html`: + +```html +<!DOCTYPE html> +<title>Simple test</title> +<script src="/resources/testharness.js"></script> +<script src="/resources/testharnessreport.js"></script> +<div id="log"></div> +<script> + +fetch_tests_from_worker(new Worker("worker.js")); + +</script> +``` + +The argument to the `fetch_tests_from_worker` function can be a +[`Worker`](https://html.spec.whatwg.org/multipage/workers.html#dedicated-workers-and-the-worker-interface), +a [`SharedWorker`](https://html.spec.whatwg.org/multipage/workers.html#shared-workers-and-the-sharedworker-interface) +or a [`ServiceWorker`](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-obj). +Once called, the containing document fetches all the tests from the worker and +behaves as if those tests were running in the containing document itself. + +## List of Assertions ## + +### `assert_true(actual, description)` +asserts that `actual` is strictly true + +### `assert_false(actual, description)` +asserts that `actual` is strictly false + +### `assert_equals(actual, expected, description)` +asserts that `actual` is the same value as `expected` + +### `assert_not_equals(actual, expected, description)` +asserts that `actual` is a different value to `expected`. +This means that `expected` is a misnomer. + +### `assert_in_array(actual, expected, description)` +asserts that `expected` is an Array, and `actual` is equal to one of the +members i.e. `expected.indexOf(actual) != -1` + +### `assert_array_equals(actual, expected, description)` +asserts that `actual` and `expected` have the same +length and the value of each indexed property in `actual` is the strictly equal +to the corresponding property value in `expected` + +### `assert_approx_equals(actual, expected, epsilon, description)` +asserts that `actual` is a number within ±`epsilon` of `expected` + +### `assert_less_than(actual, expected, description)` +asserts that `actual` is a number less than `expected` + +### `assert_greater_than(actual, expected, description)` +asserts that `actual` is a number greater than `expected` + +### `assert_between_exclusive(actual, lower, upper, description` +asserts that `actual` is a number between `lower` and `upper` but not +equal to either of them + +### `assert_less_than_equal(actual, expected, description)` +asserts that `actual` is a number less than or equal to `expected` + +### `assert_greater_than_equal(actual, expected, description)` +asserts that `actual` is a number greater than or equal to `expected` + +### `assert_between_inclusive(actual, lower, upper, description` +asserts that `actual` is a number between `lower` and `upper` or +equal to either of them + +### `assert_regexp_match(actual, expected, description)` +asserts that `actual` matches the regexp `expected` + +### `assert_class_string(object, class_name, description)` +asserts that the class string of `object` as returned in +`Object.prototype.toString` is equal to `class_name`. + +### `assert_own_property(object, property_name, description)` +assert that object has own property `property_name` + +### `assert_inherits(object, property_name, description)` +assert that object does not have an own property named +`property_name` but that `property_name` is present in the prototype +chain for object + +### `assert_idl_attribute(object, attribute_name, description)` +assert that an object that is an instance of some interface has the +attribute attribute_name following the conditions specified by WebIDL + +### `assert_readonly(object, property_name, description)` +assert that property `property_name` on object is readonly + +### `assert_throws(code, func, description)` +`code` - the expected exception. This can take several forms: + + * string - the thrown exception must be a DOMException with the given + name, e.g., "TimeoutError" (for compatibility with existing + tests, a constant is also supported, e.g., "TIMEOUT_ERR") + * object - the thrown exception must have a property called "name" that + matches code.name + * null - allow any exception (in general, one of the options above + should be used) + +`func` - a function that should throw + +### `assert_unreached(description)` +asserts if called. Used to ensure that some codepath is *not* taken e.g. +an event does not fire. + +### `assert_any(assert_func, actual, expected_array, extra_arg_1, ... extra_arg_N)` +asserts that one `assert_func(actual, expected_array_N, extra_arg1, ..., extra_arg_N)` + is true for some `expected_array_N` in `expected_array`. This only works for `assert_func` + with signature `assert_func(actual, expected, args_1, ..., args_N)`. Note that tests + with multiple allowed pass conditions are bad practice unless the spec specifically + allows multiple behaviours. Test authors should not use this method simply to hide + UA bugs. + +### `assert_exists(object, property_name, description)` +**deprecated** +asserts that object has an own property `property_name` + +### `assert_not_exists(object, property_name, description)` +**deprecated** +assert that object does not have own property `property_name` + +## Metadata ## + +It is possible to add optional metadata to tests; this can be done in +one of two ways; either by adding `<meta>` elements to the head of the +document containing the tests, or by adding the metadata to individual +`[async_]test` calls, as properties. diff --git a/testing/web-platform/tests/resources/docs/idlharness.md b/testing/web-platform/tests/resources/docs/idlharness.md new file mode 100644 index 000000000..141077b3a --- /dev/null +++ b/testing/web-platform/tests/resources/docs/idlharness.md @@ -0,0 +1,128 @@ +## Introduction ## + +`idlharness.js` automatically generates browser tests for WebIDL interfaces, using +the testharness.js framework. To use, first include the following: + +```html +<script src=/resources/testharness.js></script> +<script src=/resources/testharnessreport.js></script> +<script src=/resources/WebIDLParser.js></script> +<script src=/resources/idlharness.js></script> +``` + +Then you'll need some type of IDLs. Here's some script that can be run on a +spec written in HTML, which will grab all the elements with `class="idl"`, +concatenate them, and replace the body so you can copy-paste: + +```js +var s = ""; +[].forEach.call(document.getElementsByClassName("idl"), function(idl) { + //https://www.w3.org/Bugs/Public/show_bug.cgi?id=14914 + if (!idl.classList.contains("extract")) + { + s += idl.textContent + "\n\n"; + } +}); +document.body.innerHTML = '<pre></pre>'; +document.body.firstChild.textContent = s; +``` + +Once you have that, put it in your script somehow. The easiest way is to +embed it literally in an HTML file with `<script type=text/plain>` or similar, +so that you don't have to do any escaping. Another possibility is to put it +in a separate .idl file that's fetched via XHR or similar. Sample usage: + +```js +var idl_array = new IdlArray(); +idl_array.add_untested_idls("interface Node { readonly attribute DOMString nodeName; };"); +idl_array.add_idls("interface Document : Node { readonly attribute DOMString URL; };"); +idl_array.add_objects({Document: ["document"]}); +idl_array.test(); +``` + +This tests that `window.Document` exists and meets all the requirements of +WebIDL. It also tests that window.document (the result of evaluating the +string "document") has URL and nodeName properties that behave as they +should, and otherwise meets WebIDL's requirements for an object whose +primary interface is Document. It does not test that window.Node exists, +which is what you want if the Node interface is already tested in some other +specification's suite and your specification only extends or refers to it. +Of course, each IDL string can define many different things, and calls to +add_objects() can register many different objects for different interfaces: +this is a very simple example. + +## Public methods of IdlArray ## + +IdlArray objects can be obtained with `new IdlArray()`. Anything not +documented in this section should be considered an implementation detail, +and outside callers should not use it. + +### `add_idls(idl_string)` + Parses `idl_string` (throwing on parse error) and adds the results to the + IdlArray. All the definitions will be tested when you run test(). If + some of the definitions refer to other definitions, those must be present + too. For instance, if `idl_string` says that `Document` inherits from `Node`, + the `Node` interface must also have been provided in some call to `add_idls()` + or `add_untested_idls()`. + +### `add_untested_idls(idl_string)` + Like `add_idls()`, but the definitions will not be tested. If an untested + interface is added and then extended with a tested partial interface, the + members of the partial interface will still be tested. Also, all the + members will still be tested for objects added with `add_objects()`, because + you probably want to test that (for instance) window.document has all the + properties from `Node`, not just `Document`, even if the `Node` interface itself + is tested in a different test suite. + +### `add_objects(dict)` + `dict` should be an object whose keys are the names of interfaces or + exceptions, and whose values are arrays of strings. When an interface or + exception is tested, every string registered for it with `add_objects()` + will be evaluated, and tests will be run on the result to verify that it + correctly implements that interface or exception. This is the only way to + test anything about `[NoInterfaceObject]` interfaces, and there are many + tests that can't be run on any interface without an object to fiddle with. + + The interface has to be the *primary* interface of all the objects + provided. For example, don't pass `{Node: ["document"]}`, but rather + `{Document: ["document"]}`. Assuming the `Document` interface was declared to + inherit from `Node`, this will automatically test that document implements + the `Node` interface too. + + Warning: methods will be called on any provided objects, in a manner that + WebIDL requires be safe. For instance, if a method has mandatory + arguments, the test suite will try calling it with too few arguments to + see if it throws an exception. If an implementation incorrectly runs the + function instead of throwing, this might have side effects, possibly even + preventing the test suite from running correctly. + +### `prevent_multiple_testing(name)` + This is a niche method for use in case you're testing many objects that + implement the same interfaces, and don't want to retest the same + interfaces every single time. For instance, HTML defines many interfaces + that all inherit from `HTMLElement`, so the HTML test suite has something + like + +```js +.add_objects({ + HTMLHtmlElement: ['document.documentElement'], + HTMLHeadElement: ['document.head'], + HTMLBodyElement: ['document.body'], + ... +}) +``` + + and so on for dozens of element types. This would mean that it would + retest that each and every one of those elements implements `HTMLElement`, + `Element`, and `Node`, which would be thousands of basically redundant tests. + The test suite therefore calls `prevent_multiple_testing("HTMLElement")`. + This means that once one object has been tested to implement `HTMLElement` + and its ancestors, no other object will be. Thus in the example code + above, the harness would test that `document.documentElement` correctly + implements `HTMLHtmlElement`, `HTMLElement`, `Element`, and `Node`; but + `document.head` would only be tested for `HTMLHeadElement`, and so on for + further objects. + +### `test()` + Run all tests. This should be called after you've called all other + methods to add IDLs and objects. |