Skip to content
Snippets Groups Projects
Select Git revision
  • master default
  • proposed-rewrite-strategy-for-fixtures-with-assertions
  • travisbuddy
  • _syntax
  • update-expressions
  • features-cleanup
  • v8-with-all-flags
  • promise-constructor-override
  • jugglinmike-refactor-for-parsers-directive
  • donprinthandle
  • remove-issafeinteger-followup
  • bigint-fix-minvalue
  • revert-1176-1051
  • ljharb-finally
  • revert-1141-ArrayIteratorPrototype-next
  • revert-1150-revert-1064-class-fields
  • dev
  • es5-tests
18 results
Blame Permalink
After you've reviewed these contribution guidelines, you'll be all set to contribute to this project.
CONTRIBUTING.md 18.36 KiB

Test262 Authoring Guidelines

Source Material

Test Case Names

Test cases should be created in files that are named to identify the feature or API that's being tested.

The names should use alphanumeric characters and ., -, _. Otherwise, there is no strict naming convention, but the file names should be human readable, helpful and, ideally, consistent within a single directory. For examples:

  • Math.fround handling of Infinity: test/built-ins/Math/fround/Math.fround_Infinity.js
  • Array.prototype.find use with Proxy: test/built-ins/Array/prototype/find/Array.prototype.find_callable-Proxy-1.js
  • arguments implements an iterator interface: test/language/arguments-object/iterator-interface.js

See the following directory trees for further recommended examples:

Note The project is currently transitioning from a naming system based on specification section numbers. There remains a substantial number of tests that conform to this outdated convention; contributors should ignore that approach when introducing new tests and instead encode this information using the esid frontmatter tag.

Test Case Style

A test file has three sections: Copyright, Frontmatter, and Body. A test looks roughly like this:

// Copyright (C) 2015 [Contributor Name]. All rights reserved.
// This code is governed by the BSD license found in the LICENSE file.

/*---
 description: brief description
 info: >
   verbose test description, multiple lines OK.
   (info typically contains relevant, direct quote from ECMAScript)
---*/

[Test Code]

Copyright

The copyright block must be the first section of the test. The copyright block must use // style comments.

Frontmatter

The Test262 frontmatter is a string of YAML enclosed by the comment start tag /*--- and end tag ---*/. There must be exactly one Frontmatter per test.

Test262 supports the following tags:

The following tags are deprecated, but exist in old tests:

description

description: [string]

This is one of two required frontmatter tags. The description should be a short, one-line description of the purpose of this testcase. We suggested that the description be kept to less than 100 characters, but clarity is preferred over brevity.

Eg: Insert <LS> between chunks of one string

info

info: [multiline string]

This allows a long, free-form comment. The comment is almost always a direct quote from ECMAScript. It is used to indicate the observable being tested within the file.

For example:

/*---
esid: sec-weakset.prototype.has
description: Throws TypeError if `this` is not Object.
info: |
  WeakSet.prototype.has ( value )

  1. Let S be the this value.
  2. If Type(S) is not Object, throw a TypeError exception.
---*/

Note: Adding more context than the direct quote from ECMAScript should rarely be necessary. If you must add context to the quote, use the JavaScript single line comment syntax.

negative

negative: [dictionary containing phase and type]

This means the test is expected to throw an error of the given type. If no error is thrown, a test failure is reported.

  • type- If an error is thrown, it is implicitly converted to a string. In order for the test to pass, this value must match the name of the error constructor.
  • phase - Negative tests whose phase value is "parse" must produce the specified error prior to executing code. The value "resolution" indicates that the error is expected to result while performing ES2015 module resolution. The value "runtime" dictates that the error is expected to be produced as a result of executing the test code.

For best practices on how to use the negative tag please see Handling Errors and Negative Test Cases, below.

For example:

negative:
  phase: parse
  type: ReferenceError

esid

esid: [spec-id]