rhino/testsrc
andrea.bergia 15abaadb78 Fix unhandled promise rejection handler after a `.then`
If we have a promise `p1` that is rejected, and invoke `then` on it,
we create a new promise `p2` (as it should be, per the spec) and mark
`p1` as handled. However, if we call `.catch` on `p2`, we are _not_
marking `p1` as handled correctly since its status is "pending" and
not "rejected". This patch fixes it and adds some tests.

Fixes #1461
2024-05-03 16:04:47 -07:00
..
benchmarks Update SunSpider benchmarks (#1375) 2023-08-18 16:07:59 -07:00
com/example/securitytest Classcache must honor current security context. (#1019) 2021-09-28 23:39:22 -07:00
doctests Fix failing string.trim.doctest in java11. 2020-06-29 11:21:58 -07:00
jstests a bit cleanup for the PR; make the old function markFunctionStart(int) deprecated and do not use the old stuff internally 2024-04-27 15:29:48 +02:00
org/mozilla Fix unhandled promise rejection handler after a `.then` 2024-05-03 16:04:47 -07:00
tests some code cleanup for array at support (#1331) 2023-05-31 17:16:15 +02:00
README.md update test262 +test262.properties file (re)generator (#930) 2021-06-23 14:47:57 -07:00
assert.js Update assert.js to handle e4x objects 2021-04-12 13:21:25 -07:00
opt-1.tests Disable a very old flaky test 2021-10-08 16:52:13 -07:00
opt0.tests Disable a very old flaky test 2021-10-08 16:52:13 -07:00
opt9.tests Disable a very old flaky test 2021-10-08 16:52:13 -07:00
test-async.js Implement promises (#942) 2021-08-06 15:12:46 -07:00
test262.properties initial implementation of function rest parameter support (#1451) 2024-04-28 15:07:35 -07:00

README.md

Running tests

./gradlew test

Runs the MozillaSuiteTest (and the Test262Suite if installed) 3 times (at optimization levels -1, 0 and 9) Results can be found in ./buildGradle/reports/tests/test/index.html

Running the official ECMAScript Test Suite (test262)

The Rhino test source contains logic to additionally run the official ECMAScript Test Suite. In order to do so, the test suite first needs to be fetched, by running the following commands:

git submodule init
git submodule update

After doing so, the ./gradlew test command will also execute all tests that are part of the official ECMAScript Test Suite

As Rhino isn't 100% compliant with the latest ECMAScript standard, there is a mechanism to define which tests to run/skip, through the test262.properties file, the format of which is discussed in the test262.properties format section

Optimization levels

By default all tests are run 3 times, at optimization levels -1, 0 and 9.

This behavior can be changed through different means:

  1. Quick disable (will run tests with optimization level -1)
./gradlew test -Dquick
  1. Setting an explicit optimization level through the command line:
./gradlew test -DoptLevel=9
  1. Setting an explicit optimization level through the TEST_262_OPTLEVEL environment variable

Running a specific TestSuite

./gradlew test --tests org.mozilla.javascript.tests.Test262SuiteTest

test262.properties format

The test262.properties file is used to specify which tests from the official ECMAScript Test Suite to include/exclude, so that the test suite can pass even though Rhino is not yet 100% standards compliant

The test262.properties file:

  • lists the subfolders of the test262 folder to include or exclude when running tests
  • lists the .js test files that are expected to fail per (sub)folder

Basics

built-ins/Array <- include all the tests in the test262/built-ins/Array folder
    from/calling-from-valid-1-noStrict.js <- but expect that this tests fails

If built-ins/Array/from/calling-from-valid-1-noStrict.js indeed fails, it wont fail the test suite. If it passes, this will be logged while running the test suite

Skipping entire folders

~built-ins/decodeURI
    name.js
    S15.1.3.1_A2.4_T1.js
    S15.1.3.1_A5.2.js

Toplevel folders can be prefixed with a ~ to mark the folder to be skipped entirely, for example because it contains all tests for a feature not yet supported by Rhino or because running the tests take a long time. Any files listed for a skipped folder will be skipped as well.

Expecting all files in a (sub)folder to fail

built-ins/Array <-- topLevel folder
    prototype/flatMap <-- subfolder under topLevel folder

If all files in a subfolder below a topLevel folderare expected to fail, instead of listing all files explicitly, just the path of the folder needs to be included under the topLevel folder

Comments The test262.properties file uses the Java Properties format, with the folder/.js file paths being the property key. The value of each 'property' can be used to store a comment

~built-ins/Array All tests on the built-in Array class
    prototype/flatMap haven't gotten around to implementing flatMap yet

A Java Properties file can also have entire lines as comments, by prefixing the line with either ! or #. While the test262.properties file does support this (because it is a Java Properties file), such line comments will be lost when (re)generating the test262.properties file!

Updating the test262.properties file

While the test262.properties file could be manually updated, the tooling also comes with a mechanism to (re)generate the file based on the current revision of the test262 submodule and the results of running Test262SuiteTest against this revision on all standard optLevels (-1, 0 & 9)

./gradlew test --tests org.mozilla.javascript.tests.Test262SuiteTest --rerun-tasks -DupdateTest262properties [-Dtest262properties=testsrc/myOwn.properties]

The .properties file generation can be parameterized to affect the output:

  • rollup: include only a single line for a subfolder that contains only failing tests
  • stats: include stats on the # of failed and total tests
  • unsupported: include files containing tests for unsupported features

These defaults can be overridden by specifying a value for the generateTest262properties parameter:

  • all: rollup, stats and unsupported all true (default)
  • none: rollup, stats and unsupported all false
  • [rollup][stats][unsupported]: the ones included will be true

Note: the tests must actually run for the .properties file to be updated. If gradle determines that nothing has changed since the last time the test command was run, it won't run the tests. The --rerun-tasks argument forces gradle to run all tests

Running specific tests from the official ECMAScript Test Suite (test262)

The default setup for running the test262 test suite is defined in test262.properties.

Another .properties file to use can be specified using the test262properties commandline property

./gradlew test --tests org.mozilla.javascript.tests.Test262SuiteTest -Dtest262properties=testsrc/myOwn.properties

This allows the creation of a custom .properties file containing for example just the tests for one specific feature being implemented, which allows for (quickly) running just the tests for that specific feature