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) or send an e-mail to admin@wiki.whatwg.org with your desired username and an explanation of the first edit you'd like to make. (Do not use this e-mail address for any other inquiries, as they will be ignored or politely declined.)

Note: This wiki is used to supplement, not replace, specification discussions. If you would like to request changes to existing specifications, please use IRC or a mailing list first.

Testsuite

From WHATWG Wiki
Jump to: navigation, search

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