test262 & conformance

One shared set of tests for every engine

A JavaScript engine is the program that runs your JavaScript. Chrome and Node.js use V8, Firefox uses SpiderMonkey, and Safari uses JavaScriptCore. All of them follow the same rulebook, the ECMAScript specification, or spec for short.

But how do we know that every engine really follows it? Each engine is checked against one shared set of tests, called test262. TC39, the group that writes the spec, keeps these tests next to the spec. There are tens of thousands of them, and each one is a small JavaScript file that checks one rule.

A test passes when it runs to the end without throwing an error. It fails when it throws. Here is the core of a tiny test:

const cart = [3, 4, 5];
assert.sameValue(cart.at(-1), 5);
assert.sameValue(cart.at(0), 3);
console.log("both checks passed");

Line 1 makes an array called cart with three prices: 3, 4 and 5.

Line 2 checks one rule about at(). The at() method reads an item by its position. A negative position counts back from the end, so cart.at(-1) is the last item, 5. assert.sameValue takes two values: the value the code gave, and the value the spec says it should give. If they are the same, it does nothing. If they differ, it throws an error.

Line 3 checks that cart.at(0) is the first item, 3. Both checks pass, so nothing is thrown, and line 4 prints "both checks passed". Real tests don't print anything. Line 4 is only there so you can see that the program reached the end.

assert.sameValue isn't part of JavaScript. It comes from test262's helper files. In this lesson, the editor first loads a small model of those helpers, written for the lesson, so you can run every example. You'll read that model in the harness section below.

Now see what a failing check looks like. This example expects the wrong value on purpose.

const cart = [3, 4, 5];
try {
  assert.sameValue(cart.at(-1), 4, "at(-1) reads the last item.");
} catch (error) {
  console.log(String(error));
}

Line 1 makes the same cart. Line 3 expects cart.at(-1) to be 4, which is wrong: it is 5. The third value on line 3 is a message that says what the check is about.

So assert.sameValue throws a Test262Error, the error type test262 uses for a failed check. Lines 2 and 4 catch the error, so the program doesn't stop, and line 5 prints it: Test262Error: at(-1) reads the last item. Expected SameValue(«5», «4») to be true. The marks « and » wrap each value: first the value the code gave, then the value the test expected.

What the test262 suite holds

A set of tests that belong together is called a test suite. test262 is a project on GitHub, at github.com/tc39/test262. Here are its main folders.

test262/
  INTERPRETING.md   how a runner must run each test
  harness/          assert.js, sta.js, propertyHelper.js, ...
  test/
    built-ins/      Array, Promise, JSON, Temporal, ...
    language/       statements, expressions, literals, ...
    annexB/         old web features from Annex B
    intl402/        Intl, from the separate ECMA-402 spec
    staging/        new tests that are still being checked

Line 1 is the project folder. Line 2 is INTERPRETING.md, the rules for a runner. A runner is the program that runs each test in an engine and records whether it passed. The rules say which helper files to load and how many times to run each test.

Line 3 is harness/, the folder of helper files, such as assert.js. Line 4 is test/, which holds the tests themselves. Lines 5 to 9 are the folders inside test/.

The table below lists what each folder is for. Read each row as: "the tests in this folder check this."

Each folder splits further, down to one feature. For example, the tests for at() on arrays sit in test/built-ins/Array/prototype/at/. Each file in that folder checks one rule about at().

Many people write tests: the people who propose a new feature, engine teams, and volunteers. A new feature needs test262 tests before it can join the spec, so the tests are ready before most people can use the feature.

Reading a test: the metadata block

A real test file has two parts. First comes a block of facts about the test, called metadata. Then comes the test code. Here is a whole test file for at().

// Copyright (C) 2026 Asha. All rights reserved.
// This code is governed by the BSD license found in the LICENSE file.
/*---
esid: sec-array.prototype.at
description: at() counts back from the end for a negative index
info: |
  Let relativeIndex be ? ToIntegerOrInfinity(index).
  If relativeIndex >= 0, let k be relativeIndex.
  Else, let k be len + relativeIndex.
features: [Array.prototype.at]
---*/

var cart = [3, 4, 5];
assert.sameValue(cart.at(-1), 5, "at(-1) reads the last item");
assert.sameValue(cart.at(-3), 3, "at(-3) reads the first item");
assert.sameValue(cart.at(-4), undefined, "at(-4) is before the first item");

Lines 1 and 2 are the copyright note that every test file starts with. The name and year change from file to file.

Line 3, /*---, opens the metadata block, and line 11, ---*/, closes it. The block is inside a comment, so the engine skips it. The runner reads it to decide how to run the test. The block uses YAML, a simple format where each line is a name, a colon, and a value.

• Line 4, esid, names the spec section this test checks. sec-array.prototype.at is the id at the end of that section's web address.
• Line 5, description, says in one line what the test checks.
• Line 6, info, holds longer notes. The | means "the next lines all belong here". Here, lines 7 to 9 copy the spec steps the test is about.
• Line 10, features, lists the features the test needs. A runner can skip the test in an engine that doesn't have Array.prototype.at yet.

Lines 7 to 9 are spec steps. Spec steps read like a recipe. "Let x be …" means "call the result x". A ? means "if this step goes wrong, stop and throw the error". In plain words, line by line:

7. Turn the position you passed in into a whole number. ToIntegerOrInfinity drops any part after the decimal point. Call the result relativeIndex.
8. If it is 0 or more, use it as the position k.
9. Otherwise, count back from the end: add it to len, the length of the array.

So for at(-1) on a 3-item array, k is 3 + -1 = 2, the last position.

Lines 13 to 16 are the test code. Line 13 makes the same cart as before. Line 14 checks that at(-1) gives the last item, 5. Line 15 checks that at(-3) gives the first item, 3: 3 + -3 = 0. Line 16 checks that at(-4) gives undefined: 3 + -4 = -1, which is before the first item, so there is nothing to read. Each check has a message, so a failure says which rule broke.

The table below lists the metadata names you'll see most. Read each row as: "when a test has this name in its metadata, it tells the runner this."

You'll meet includes, negative and flags in the next three sections.

The harness: assert.sameValue, assert.throws and includes

The harness is the set of helper files a runner loads before each test. Two of them are loaded for almost every test:

• sta.js makes Test262Error, the error a failed check throws, and $DONOTEVALUATE, which you'll meet in the next section.
• assert.js makes assert and its checks, such as assert.sameValue and assert.throws.

The real files have more checks and handle more cases. The model below is small and was written for this lesson, but it works the same way for every example here. The editor loads it before each example, so you don't run it yourself.

function Test262Error(message) {
  this.message = message || "";
}
Test262Error.prototype.toString = function () {
  return "Test262Error: " + this.message;
};
function $DONOTEVALUATE() {
  throw "Test262: This statement should not be evaluated.";
}
function assert(mustBeTrue, message) {
  if (mustBeTrue !== true) throw new Test262Error(message);
}
assert._format = function (value) {
  if (Object.is(value, -0)) return "-0";
  return typeof value === "string" ? JSON.stringify(value) : String(value);
};
assert.sameValue = function (actual, expected, message) {
  if (Object.is(actual, expected)) return;
  const reason = "Expected SameValue(«" + assert._format(actual) + "», «" + assert._format(expected) + "») to be true";
  throw new Test262Error(message ? message + " " + reason : reason);
};
assert.throws = function (expectedError, func) {
  try {
    func();
  } catch (thrown) {
    if (thrown?.constructor === expectedError) return;
    throw new Test262Error("Expected a " + expectedError.name + " but got a " + thrown?.constructor?.name);
  }
  throw new Test262Error("Expected a " + expectedError.name + " to be thrown but no exception was thrown at all");
};

• Lines 1 to 3 make Test262Error. Line 2 keeps the message it is given.
• Lines 4 to 6 say how the error turns into text: "Test262Error: " and then the message. That is the text the examples print.
• Lines 7 to 9 make $DONOTEVALUATE. Line 8 throws a plain string as soon as it is called.
• Lines 10 to 12 make assert itself. Line 11 throws a Test262Error unless the value is exactly true.
• Lines 13 to 16 make a helper that turns a value into text for a message. Line 14 shows -0 as "-0", because plain String(-0) gives "0". Line 15 puts quotes around text.
• Lines 17 to 21 make assert.sameValue. Line 18 returns quietly if the two values are the same. Line 19 builds the message, and line 20 throws it.
• Lines 22 to 30 make assert.throws. Line 24 calls the function it is given. If that throws, line 26 checks which constructor made the error, and line 27 fails if it is the wrong one. Line 29 fails if nothing was thrown at all.

Line 18 uses Object.is, which follows the spec's SameValue rule. It is almost the same as ===, with two differences: NaN is the same as NaN, and -0 is not the same as 0. Test262 needs this, because the spec often cares about -0.

assert.sameValue(NaN, NaN);
assert.sameValue(0.1 + 0.2 === 0.3, false);
try {
  assert.sameValue(-0, 0);
} catch (error) {
  console.log(String(error));
}

Line 1 compares NaN with NaN. NaN === NaN is false, but under SameValue they are the same, so the check passes and prints nothing.

Line 2 shows a common way to check a true or false result. 0.1 + 0.2 is 0.30000000000000004, so 0.1 + 0.2 === 0.3 is false. The test expects false, so this check passes too.

Line 4 compares -0 with 0. -0 === 0 is true, but under SameValue they differ, so the check throws. Lines 5 and 6 catch the error and print Test262Error: Expected SameValue(«-0», «0») to be true.

The table below compares the two rules. Read each row as: "when I compare these two values, === says this, and assert.sameValue does this."

Some rules in the spec say "throw a TypeError here". assert.throws checks rules like that. You give it the error you expect and a function. It calls the function and checks that it throws that kind of error.

assert.throws(TypeError, function () {
  null.price;
});
try {
  assert.throws(TypeError, function () {
    return [3, 4].at(5);
  });
} catch (error) {
  console.log(String(error));
}

Line 1 expects a TypeError. Line 2 reads a property of null, which throws a TypeError. That is the error line 1 asked for, so the check passes and prints nothing.

Line 5 expects a TypeError too. But line 6 reads [3, 4].at(5), which is past the end of the array. at() doesn't throw for that. It just gives undefined. No error comes out, so assert.throws throws its own Test262Error. Lines 8 and 9 catch it and print Test262Error: Expected a TypeError to be thrown but no exception was thrown at all.

1assert.throws(TypeError, function () {Run2  null.price;3});4try {5  assert.throws(TypeError, function () {6    return [3, 4].at(5);7  });8} catch (error) {9  console.log(String(error));10}

Press Step to walk through both checks. Watch the second one: the function returns undefined, and the failure comes from assert.throws, not from at(). The checks run for real in the lesson's small model of assert.js. This replays the example code; it isn't a view inside the JavaScript engine.

Some tests need more helpers than assert.js has. They ask for them with includes in the metadata block. This test checks how the at property is stored on Array.prototype, the object every array gets its methods from.

/*---
esid: sec-array.prototype.at
description: at is writable and configurable, but not enumerable
includes: [propertyHelper.js]
features: [Array.prototype.at]
---*/

verifyProperty(Array.prototype, "at", {
  writable: true,
  enumerable: false,
  configurable: true,
});

Lines 1 to 6 are the metadata block. Line 4 lists propertyHelper.js under includes. That file makes verifyProperty, a check for the settings of one property.

Lines 8 to 12 call verifyProperty. Line 8 names the object and the property: at on Array.prototype. Lines 9 to 11 list three settings every property has:

• Line 9, writable: true: code can change the property's value.
• Line 10, enumerable: false: the property doesn't show up in a for...in loop.
• Line 11, configurable: true: code can delete the property or change its settings.

This example can't run here, because the lesson's model doesn't include propertyHelper.js.

You can read the same three settings yourself, in plain JavaScript:

const descriptor = Object.getOwnPropertyDescriptor(Array.prototype, "at");
console.log(descriptor.writable, descriptor.enumerable, descriptor.configurable);

Line 1 calls Object.getOwnPropertyDescriptor, which gives back an object that describes one property: its value and its settings. Line 2 prints the three settings: true false true. They match lines 9 to 11 of the test, so that test passes in this browser.

Negative tests: code that must fail

The spec doesn't only say what code does. It also says which code is not allowed at all. Some mistakes must be found while the engine reads the code, before any of it runs. The spec calls these early errors. They are thrown as a SyntaxError.

A negative test checks that the engine rejects such code. It passes only if the right error is thrown at the right time.

/*---
esid: sec-block-static-semantics-early-errors
description: A block can't declare the same let name twice
negative:
  phase: parse
  type: SyntaxError
---*/

$DONOTEVALUATE();

{
  let price = 3;
  let price = 4;
}

Lines 1 to 7 are the metadata block. Lines 4 to 6 make this a negative test:

• Line 4, negative, says the test must throw.
• Line 5, phase: parse, says when: while the engine reads the code, before anything runs.
• Line 6, type: SyntaxError, says which error.

Lines 11 to 14 are the code that must be rejected: a block that declares let price twice. The spec forbids that, so the engine must throw a SyntaxError.

Line 9 calls $DONOTEVALUATE(), which throws as soon as it runs. In a correct engine, it never runs, because the whole file is rejected first. But if an engine wrongly accepts the code, line 9 is the first line to run. It throws a plain string, not a SyntaxError, so the test fails.

The table below lists the three phases a negative test can name. Read each row as: "when a test says this phase, the error must happen at this time."

This example can't run as written: the editor would just show the SyntaxError. To run it, you need a runner that reads the metadata and checks the error. Here is a tiny model of a runner, written for this lesson. Like the harness model, the editor loads it before each example.

function runOnce(code) {
  let phase = "parse";
  try {
    const test = new Function(code);
    phase = "runtime";
    test();
    return { phase: null, error: null };
  } catch (error) {
    return { phase, error };
  }
}
function runTest(name, source, meta = {}) {
  const flags = meta.flags ?? [];
  let modes = ["non-strict", "strict"];
  if (flags.includes("onlyStrict")) modes = ["strict"];
  if (flags.includes("noStrict")) modes = ["non-strict"];
  for (const mode of modes) {
    const code = mode === "strict" ? '"use strict";\n' + source : source;
    const { phase, error } = runOnce(code);
    const negative = meta.negative;
    const passed = negative
      ? phase === negative.phase && error?.constructor?.name === negative.type
      : error === null;
    console.log(name + " (" + mode + "): " + (passed ? "pass" : "fail, " + (error ?? "no error")));
  }
}

Lines 1 to 11 make runOnce, which runs one piece of code and reports what happened:

• Line 2 sets phase to "parse", because the engine reads the code first.
• Line 4 turns the text into a function with new Function. This is where the engine reads the code. An early error is thrown here, while phase is still "parse".
• Line 5 sets phase to "runtime", and line 6 runs the code.
• Line 7 reports no error. Line 9 reports the phase and the error, if anything was thrown.

Lines 12 to 26 make runTest, which runs a whole test:

• Lines 13 to 16 decide which modes to run. You'll use them in the flags section.
• Line 17 loops over the modes, and line 18 puts "use strict" on top for the strict run.
• Line 19 runs the code once.
• Lines 20 to 23 decide whether the run passed. A negative test passes when the phase and the error type both match. Any other test passes when nothing was thrown.
• Line 24 prints one line per run: the test name, the mode, and "pass" or "fail" with the error.

const source = `$DONOTEVALUATE();
{
  let price = 3;
  let price = 4;
}`;
runTest("duplicate let", source, {
  negative: { phase: "parse", type: "SyntaxError" },
});

Lines 1 to 5 keep the test code as text, between backticks. It is lines 9 to 14 of the test file, without the empty lines. Lines 6 to 8 call runTest and pass the same facts as the metadata block: phase "parse" and type "SyntaxError".

With no flags, the runner runs the test twice. Both times, the engine rejects the two let price lines while reading, so $DONOTEVALUATE() on line 1 never runs. The program prints duplicate let (non-strict): pass and then duplicate let (strict): pass.

Flags: strict, non-strict, module and async runs

JavaScript has two modes. Writing "use strict" on the first line of a script turns on strict mode. Strict mode turns some old, error-prone features into errors, and changes a few rules. Code without it runs in non-strict mode, often called sloppy mode.

The spec describes both modes, so a test must pass in both, unless it says otherwise. It says otherwise with flags in its metadata block. The table below lists the flags that change how a test runs. Read each row as: "when a test lists this flag, the runner runs it like this."

Here is a test that only works in one of the two modes. It runs in the model runner twice: once with no flags, and once with onlyStrict.

const source = `function kind() {
  return typeof this;
}
assert.sameValue(kind(), "undefined");`;
runTest("no flags", source);
runTest("onlyStrict", source, { flags: ["onlyStrict"] });

Lines 1 to 4 keep the test as text. Lines 1 to 3 make kind, which returns typeof this: the type of the value this holds. Line 4 calls kind() on its own, not as a method of an object, and expects "undefined".

Line 5 runs the test with no flags, so it runs twice:

• In the non-strict run, a call on its own gets the global object as this. So kind() gives "object", and the check fails: no flags (non-strict): fail, Test262Error: Expected SameValue(«"object"», «"undefined"») to be true.
• In the strict run, a call on its own gets undefined as this. So the check passes: no flags (strict): pass.

Line 6 runs the same test with onlyStrict. The runner skips the non-strict run, so the only line is onlyStrict (strict): pass. The test itself was fine. It only needed the right flag.

1const source = `function kind() {Run2  return typeof this;3}4assert.sameValue(kind(), "undefined");`;5runTest("no flags", source);6runTest("onlyStrict", source, { flags: ["onlyStrict"] });

Step through lines 5 and 6. Watch how many runs each call plans, and where "use strict" is put on top. The test runs for real in the lesson's small model runner. This replays the example code; it isn't a view inside the JavaScript engine.

Now pick the flags yourself. The playground has four tests:

• at(-1) reads the last item. It works in both modes.
• this in a plain call is the test from above.
• old octal 010 uses 010, an old way to write the number 8 with a leading zero. Strict mode doesn't allow it.
• duplicate let is the negative test from the last section.

For each test, find the flags where every run passes, and no mode is left out that the test could cover.

1/*---2description: A plain call gets undefined as this3---*/4 5function kind() {6  return typeof this;7}8assert.sameValue(kind(), "undefined");

Two more flags change how a test runs. The module flag runs the test as a module, the kind of file that can use import and export.

/*---
esid: sec-module-semantics
description: Code in a module is always strict
flags: [module]
---*/

function kind() {
  return typeof this;
}
assert.sameValue(kind(), "undefined");

Line 4 lists the module flag. Lines 7 to 10 are the same check as before: a call on its own must get undefined as this. Code in a module is always strict, so this test passes without "use strict". The runner runs it once, as a module, and adds nothing.

The async flag is for tests that finish later, such as tests of promises. A promise is an object for a value that may arrive later.

/*---
esid: sec-promise.resolve
description: Promise.resolve gives a promise that settles with the value
flags: [async]
---*/

Promise.resolve(3).then(function (price) {
  assert.sameValue(price, 3);
}).then($DONE, $DONE);

Line 4 lists the async flag, so the runner also loads a harness file that makes $DONE, and waits for it to be called. Line 7 makes a promise that settles with 3, and asks for a function to run when it does. Line 8 checks the value.

Line 9 calls $DONE when the check is finished. If the check passed, $DONE is called with no error, and the test passes. If the check threw, the second $DONE gets the error, and the test fails. If $DONE is never called, the test fails too.

Why engines get different results

An engine that follows the spec is said to conform to it. Conformance is how closely it does. In practice, no engine passes every test262 test, and that's normal. The failures have different causes.

The first cause is features that aren't shipped yet. A runner reads the features list to skip those tests. This example makes the same kind of check in your browser:

const features = {
  "Array.prototype.at": typeof Array.prototype.at === "function",
  "array-grouping": typeof Object.groupBy === "function",
  Temporal: typeof globalThis.Temporal === "object",
};
for (const [name, ready] of Object.entries(features)) {
  console.log(name + ": " + (ready ? "run its tests" : "skip its tests"));
}

Lines 1 to 5 make an object with one entry per feature. Each name is the one test262 uses in its features lists. Each value is true if the feature is there:

• Line 2 checks that arrays have an at method.
• Line 3 checks for Object.groupBy. Test262 lists it under the name "array-grouping".
• Line 4 checks for Temporal, the newer way to work with dates and times.

Lines 6 to 8 print one line per feature. The output depends on your browser. In a browser without Temporal, the last line is "Temporal: skip its tests".

The table below lists the common reasons a test fails in an engine. Read each row as: "when a test fails for this reason, it means this."

Engine teams run test262 often, and each keeps a list of the tests it is known to fail. So when a change makes a new test fail, the team sees it at once. Some websites, such as test262.fyi, run the whole suite in many engines and show how many tests each one passes.

A higher score doesn't make one engine better for your page. What matters is whether the features you use work the same everywhere you need them.

Reporting an engine bug with a small test

Now and then, a program gives a result that looks impossible, and it's tempting to blame the engine. Here is a small app that seems to read the wrong price.

const cart = [3, 4, 5];
const step = 0.5;
function lastPrice(items) {
  return items.at(-step);
}
console.log(lastPrice(cart));

Line 1 makes the cart of prices. Line 2 sets step to 0.5. Lines 3 to 5 make lastPrice, which should read the last item: line 4 calls items.at(-step), which is items.at(-0.5). Line 6 prints 3, not the last price, 5.

Before you report a bug, work through four steps.

Step 1: shrink it. Cut the code down to the smallest piece that still shows the strange result. Leave out your libraries, because they can change built-in objects. The smallest code that still shows a problem is called a reproduction.

console.log([3, 4, 5].at(-0.5));
console.log([3, 4, 5].at(-1));

Line 1 prints 3: at(-0.5) reads the first item. Line 2 prints 5: at(-1) reads the last item. So the strange result comes from the -0.5.

Step 2: check the spec. Look up the steps for at(), the same steps as lines 7 to 9 of the test file earlier. Step 3 of the spec's at() uses ToIntegerOrInfinity, which drops the part after the decimal point. So -0.5 becomes 0. 0 is not below 0, so the position is 0: the first item, 3.

So the engine is right, and the bug is in the app: line 2 should set step to 1. Most strange results end here. The spec check takes a few minutes and saves everyone time.

Step 3: write it as a test. A tiny test in test262 style makes the expected result clear, and you can run it in any engine.

/*---
esid: sec-array.prototype.at
description: at() turns -0.5 into 0, so it reads the first item
features: [Array.prototype.at]
---*/

assert.sameValue([3, 4, 5].at(-0.5), 3);

Lines 1 to 5 are the metadata block: the spec section, a one-line description, and the feature it needs. Line 7 checks that [3, 4, 5].at(-0.5) is 3. Run it: it prints nothing, because the check passes in this browser.

Step 4: report it. If an engine did print 5 for that line, it would break the spec, and that would be a real engine bug. Here is what a good report would say.

Title: [3, 4, 5].at(-0.5) gives 5, but the spec says 3
Engine: the engine's name and exact version
Code: console.log([3, 4, 5].at(-0.5));
Expected: 3
Actual: 5
Spec: Array.prototype.at, step 3 (ToIntegerOrInfinity turns -0.5 into 0)
test262: the test that fails, or a new test like the one above

• Line 1, the title, says what happens and what the spec says, in one line.
• Line 2 names the engine and its exact version. The bug may already be fixed in a newer one.
• Line 3 is the reproduction: one line anyone can run.
• Lines 4 and 5 give the expected and the actual output, so the difference is plain.
• Line 6 points at the spec step that decides the answer.
• Line 7 names the test262 test that fails, or offers a new one like the test above.

Each engine has a public bug tracker: the Chromium issue tracker for V8, Mozilla's Bugzilla for SpiderMonkey, and WebKit's Bugzilla for JavaScriptCore. If you think a test262 test is wrong, open an issue in the test262 project on GitHub instead.

Common mix-ups

Most mix-ups about test262 come from expecting too much from a test result, or from reading an assert like plain ===.

• "An engine that passes test262 has no bugs." No. The tests only check what they cover. An engine can still have bugs in places no test checks.
• "A failing test always means an engine bug." No. The feature may not be shipped yet, language data may be missing, or the test itself may be wrong.
• "assert.sameValue compares with ===." No. It uses SameValue, like Object.is: NaN matches NaN, and -0 doesn't match 0.
• "A negative test is a broken test." No. It checks that the engine rejects code the spec forbids, with the right error at the right time.
• "Every test runs once." No. A test with no flags runs twice: once as written, and once with "use strict" on top.
• "The engine with the highest score is the best one for my page." No. A score counts all tests. Check the features your page uses instead.

The table below puts three easily confused ideas side by side. Read each row as: "this term means this, but it doesn't mean that."

Practice exercises

Each program below uses the lesson's model harness and runner, so assert and runTest are already there. Guess the result before you run it. Then use the hints if you get stuck.

let result = "pass";
try {
  assert.sameValue([3, 4, 5].at(-1), 5);
  assert.sameValue(0 / -1, 0);
} catch (error) {
  result = "fail";
}
console.log(result);

assert.sameValue(0 / -1, 0); // throws: -0 is not the same as 0
console.log(result); // fail

const source = `assert.sameValue(010, 8);`;
runTest("old octal", source);

// old octal (non-strict): pass
// old octal (strict): fail, SyntaxError

let result = "pass";
try {
  assert.throws(RangeError, function () {
    return Symbol("tea") + "";
  });
} catch (error) {
  result = String(error);
}
console.log(result);

assert.throws(TypeError, function () {
  return Symbol("tea") + "";
});

let result = "pass";
try {
  assert.sameValue([3, NaN, 5].indexOf(NaN), 1);
} catch (error) {
  result = String(error);
}
console.log(result);

assert.sameValue([3, NaN, 5].indexOf(NaN), -1);

const source = `var cart = { price: 3 };
with (cart) {
  assert.sameValue(price, 3);
}`;
runTest("with", source);

runTest("with", source, { flags: ["noStrict"] });
// with (non-strict): pass

const source = `$DONOTEVALUATE();
function add(price, price) {
  return price;
}`;
runTest("duplicate parameters", source, {
  negative: { phase: "parse", type: "SyntaxError" },
});

runTest("duplicate parameters", source, {
  flags: ["onlyStrict"],
  negative: { phase: "parse", type: "SyntaxError" },
});
// duplicate parameters (strict): pass

Check your understanding

For each question, ask: what does the metadata tell the runner, which runs happen, and does anything throw? Each answer explains why it's right or wrong.

Key takeaways

Every engine reads the same spec, and test262 checks that they all read it the same way.

• test262 is the official set of tests for the ECMAScript spec. Every major engine runs it.
• A test passes when it runs to the end without throwing. A failed check throws a Test262Error.
• The metadata block tells the runner how to run the test: esid, features, includes, flags and negative.
• assert.sameValue compares like Object.is, and assert.throws checks which error a function throws.
• A negative test must throw a named error in a named phase. $DONOTEVALUATE() makes it fail if the engine wrongly runs the code.
• With no flags, a test runs twice: as written, and with "use strict" on top. onlyStrict, noStrict, module, async and raw change that.
• A failing test can mean a feature that isn't shipped, missing data, a recent spec change, an engine bug, or a wrong test.
• Before you report an engine bug, shrink the code, check the spec, and write a tiny test. Then report the version, the code, and both outputs.

Coming next: Sloppy mode in depth. It looks closely at non-strict mode, the mode that tests with noStrict check, and the old rules it still keeps.