A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on IRC (such as one of these permanent autoconfirmed members).

Difference between revisions of "Testsuite"

From WHATWG Wiki
Jump to: navigation, search
(W3C: rm dead links)
(W3C: +w3c/web-platform-tests)
Line 62: Line 62:
 
=== W3C ===
 
=== W3C ===
 
* [http://dev.w3.org/geo/api/test-suite/ Geolocation]
 
* [http://dev.w3.org/geo/api/test-suite/ Geolocation]
 +
* [https://github.com/w3c/web-platform-tests The Web Platform Tests Project]
 
* [http://hg.csswg.org/test CSS WG]
 
* [http://hg.csswg.org/test CSS WG]

Revision as of 06:55, 22 July 2015

Requirements

  • Each test needs a "reviewed" marker of some sort
  • It must be easy to find tests where the spec has changed under them
  • The barrier to contribution must be as low as possible
  • Testcases should have somewhat stable URIs
  • If test can be done using JavaScript preferably require it to be in JavaScript so engines can be more efficiently tested (i.e. automated).
  • It must be easy to review tests
  • Tests and test suites must be liberally licensed (e.g. PD/CC0, BSD, MIT)
  • Standardize a test format?

How to license your test suite

Put your test suite into the Public Domain using the Creative Commons CC0 1.0 Public Domain Dedication.

Example markup you can include in the test suite. Either one is sufficient. The visible one is preferred.

Visible (e.g. in a visible header/footer on the test suite home page):

This test suite is placed into the 
<a rel="license" 
   href="http://creativecommons.org/publicdomain/zero/1.0/">
public domain using CC0
</a>.

Invisible (e.g. inside the <head> element on the test suite home page):

<link rel="license" 
      href="http://creativecommons.org/publicdomain/zero/1.0/"
      title="This test suite is placed into the public domain using CC0." />

Non-requirements

  • There does not need to be a single consistent test harness for the whole of HTML5. (When sections can be tested in isolation, each section should use a test harness that is suited to that section's testing requirements. E.g. there is little value in fitting canvas tests and parser tests into the same framework, and it may add a lot of complexity.)

Format proposal

See http://omocha.w3.org/wiki/newformat for a format proposal that should meet most of these requirements. That format is based on the Mozilla Mochitest format for running JavaScript based client-side tests which can be run automatically.

Existing tests

W3C