In order to test this functionality on hosts that don't have Intl, we have
to use "UTC" and offset-only time zones here, as the full set of IANA time
zone names are not required to be supported across all hosts.
This makes some progress on https://github.com/tc39/test262/issues/3253
Nails down intended behavior of `PlainDate` and
`PlainDateTime`'s `since` that is already true in the
polyfill but which was specified in a buggy way (and hence
potentially not true in an implementation of Temporal).
Add similar tests for Instant, PlainTime, PlainYearMonth, and
ZonedDateTime.
Reference:
https://github.com/tc39/proposal-temporal/pull/1881
Tests for the normative changes made to Temporal in
https://github.com/tc39/proposal-temporal/pull/1873
This adds a new Temporal helper calendar that asserts that its dateAdd()
method is always called with a PlainDate instance. This allows testing
that relativeTo parameters are always converted to PlainDate if they are
not ZonedDateTime and not undefined. Prior to the normative PR, they
would be converted to PlainDateTime instead.
Additionally and optionally, the helper calendar can also assert that its
dateAdd() method is called with a specific PlainDate instance. This allows
testing that the instance is the same PlainDate passed as the relativeTo
parameter (in the case of Duration methods) or is the receiver (in the
case of PlainDate methods). For the PlainDateTime and PlainYearMonth
methods the PlainDate instance is synthesized internally so there is no
need to assert that dateAdd() is called with a specific instance.
A number of tests were found to be duplicative based on an analysis of
file contents (included below). Eliminate the duplication by removing
the version of each test with less precise metadata. In cases where this
removal could technically be considered a reduction in coverage,
preserve the verification of additional semantics in the remaining test.
$ git grep -El 'new\s+\w+.prototype' | sed 's/[^\/]\+$//g' | sort | uniq -c | grep -vE '^\s+1 ' | awk '{print $2}' | xargs grep -Elr 'new\s+\w+.prototype'
test/built-ins/Array/prototype/join/S15.4.4.5_A6.7.js
test/built-ins/Array/prototype/join/not-a-constructor.js
test/built-ins/Array/prototype/pop/not-a-constructor.js
test/built-ins/Array/prototype/pop/S15.4.4.6_A5.7.js
test/built-ins/Array/prototype/push/S15.4.4.7_A6.7.js
test/built-ins/Array/prototype/push/not-a-constructor.js
test/built-ins/Array/prototype/shift/not-a-constructor.js
test/built-ins/Array/prototype/shift/S15.4.4.9_A5.7.js
test/built-ins/Array/prototype/slice/not-a-constructor.js
test/built-ins/Array/prototype/slice/S15.4.4.10_A5.7.js
test/built-ins/Array/prototype/sort/not-a-constructor.js
test/built-ins/Array/prototype/sort/S15.4.4.11_A7.7.js
test/built-ins/Array/prototype/splice/S15.4.4.12_A5.7.js
test/built-ins/Array/prototype/splice/not-a-constructor.js
test/built-ins/Array/prototype/toLocaleString/S15.4.4.3_A4.7.js
test/built-ins/Array/prototype/toLocaleString/not-a-constructor.js
test/built-ins/Array/prototype/toString/S15.4.4.2_A4.7.js
test/built-ins/Array/prototype/toString/not-a-constructor.js
test/built-ins/Array/prototype/unshift/S15.4.4.13_A5.7.js
test/built-ins/Array/prototype/unshift/not-a-constructor.js
test/built-ins/Function/prototype/apply/S15.3.4.3_A8_T1.js
test/built-ins/Function/prototype/apply/S15.3.4.3_A8_T2.js
test/built-ins/Function/prototype/apply/not-a-constructor.js
test/built-ins/Function/prototype/call/not-a-constructor.js
test/built-ins/Function/prototype/call/S15.3.4.4_A7_T2.js
test/built-ins/Function/prototype/call/S15.3.4.4_A7_T1.js
test/built-ins/Function/prototype/toString/S15.3.4.2_A7.js
test/built-ins/Function/prototype/toString/not-a-constructor.js
test/built-ins/Object/prototype/hasOwnProperty/S15.2.4.5_A7.js
test/built-ins/Object/prototype/hasOwnProperty/not-a-constructor.js
test/built-ins/Object/prototype/propertyIsEnumerable/not-a-constructor.js
test/built-ins/Object/prototype/propertyIsEnumerable/S15.2.4.7_A7.js
test/built-ins/Object/prototype/toLocaleString/S15.2.4.3_A7.js
test/built-ins/Object/prototype/toLocaleString/not-a-constructor.js
test/built-ins/Object/prototype/toString/not-a-constructor.js
test/built-ins/Object/prototype/toString/not-ctor.js
test/built-ins/Object/prototype/valueOf/not-a-constructor.js
test/built-ins/Object/prototype/valueOf/S15.2.4.4_A7.js
The last five lines below are simply WRONG and not according to the spec.
```
const durationFormat = new Intl.DurationFormat();
verifyNotEnumerable(durationFormat, Symbol.toStringTag);
verifyNotWritable(durationFormat, Symbol.toStringTag);
verifyConfigurable(durationFormat, Symbol.toStringTag);
```
Move part of the test of toLocaleString which depends on
15 Amendments to the ECMAScript® 2021 Internationalization API Specification
to intl402. Keep behavior specified in earlier chapters in built-ins
* Add tests for "Intl NumberFormat v3" proposal
This patch is intended to cover only one aspect of the proposal for
ECMA402: the "interpret strings as decimals" feature.
* fixup! Add tests for "Intl NumberFormat v3" proposal
IANA TimeZone name other than "UTC" is only required if the implementation " includes the ECMA-402 Internationalization API"
https://tc39.es/proposal-temporal/#sec-isvalidtimezonename
Therefore, we need to split the test and keep this one without checking "America/Vancouver"
Add a case to test withtout the ":"
This patch is intended to cover only one aspect of the proposal for
ECMA402: the "grouping enum" feature. It also includes coverage for the
formatting option as already defined by the latest version of ECMA402.
Currently, this test is not conformant to the proposal text.
Temporal.TimeZone.from() calls ToTemporalTimeZone. Since the argument is
a string, we next go to ParseTemporalTimeZone, where on a string such as
`1994-11-05T08:15:30-05:00[UTC]` we would return _result_.[[Name]] (which
would be equal to `UTC`) and discard the UTC offset string.
Unfortunately, in #3304 I made a last-minute mistake when I added the
uncallable value to the assertion message, and neglected to test it;
Symbols can't be converted to strings like that, so these tests would
fail. This fixes the assertion messages.
Tests for the normative changes made to Temporal in
https://github.com/tc39/proposal-temporal/pull/1875
For convenience, adds some functions to TemporalHelpers to assert that two
Temporal objects are equal, for Duration, Instant, PlainDateTime,
PlainTime, and ZonedDateTime.
Tests for the normative changes made to Temporal in
https://github.com/tc39/proposal-temporal/pull/1829
In a previous version of the specification, there was a fallback to the
intrinsic getOffsetNanosecondsFor when it was undefined.
The Resizable ArrayBuffer proposal allows implementations to reject any
resize operation, so the tests must accommodate that possibility.
Mitigate the complexity this entails by minimizing branches and by
deferring assertions to locations with shallow call stacks.
The `arrayContains` function has a number of deficiencies which make it
inappropriate for Test262:
- It apparently isn't very useful: despite being available for over 7
years, fewer than ten tests use it
- It's misleading: its documentation reads, "Verify that a subArray is
contained within an array." In reality, it only verifies that all the
elements of one array are present in another--order does not matter.
- It's not ergonomic for test authors: it has been misused to create
tests that were prone to false positives [1]
- It's not ergonomic for implementers: ostensibly designed for use with
`assert`, the failure messages produced by tests that use it do not
necessarily have very much context
All code in the "harness" directory adds to the total amount of
project-specific information which contributors are expected to to
learn. In light of the above deficiencies, the burden of this particular
harness file is unjustified.
Remove the harness file and its associated tests. Update the tests which
depend on it to express their expectations using alternate methods, and
strengthen the tests to assert element order wherever appropriate.
[1] https://github.com/tc39/test262/pull/3289
A number of tests for ECMA402 asserted the exact contents of the array
returned by various `resolvedOptions` methods. This conflicted with the
expectation that more options will be introduced by future editions of
the specification.
Update these tests to assert property order more generically in order to
accommodate implementation of future language proposals and more closely
align with similar tests.
Update all `resolvedOptions` tests to produce more meaningful error
messages (including replacing the generic `arrayContains` assertion with
a specific assertion regarding the value of the first array element).
Prior to this patch, the modified test invoked the `arrayContains`
utility function without referencing its return value. Unlike Test262's
assertion functions, `arrayContains` does not throw an error when the
expectation is violated, so the prior usage did not influence test
results.
Additionally, the prior version of this test documented incorrect
expectations regarding the expected value produced by the method under
test. Due to the above, these expectations were not enforced.
Correct the test's expectations and enforce those expectations with a
function that will reliably produce an exception if violated.
Specify a descriptive value for the previously-unused third parameter of
the `verifyFormatParts` function in order to disambiguate error
messages.
This patch was generated with the following command:
sed -i 's/\(verifyFormatParts([^,]\+, \)\([^,]\+\))/\1\2, "\2")/g' \
test/intl402/NumberFormat/prototype/formatToParts/signDisplay-currency-*
* Sync test of Temporal.Calendar.p*.fields to 1750
https://github.com/tc39/proposal-temporal/pull
* add more test
* add more tests for T*.Calendar.p*.fields
* Update test/built-ins/Temporal/Calendar/prototype/fields/long-input.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update test/built-ins/Temporal/Calendar/prototype/fields/long-input.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update test/built-ins/Temporal/Calendar/prototype/fields/repeated-throw.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update test/built-ins/Temporal/Calendar/prototype/fields/reverse.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update test/built-ins/Temporal/Calendar/prototype/fields/reverse.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Remove loop
* Update test/built-ins/Temporal/Calendar/prototype/fields/long-input.js
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
* Update long-input.js
* Update repeated-throw.js
* Update reverse.js
* ensure the implementation check the content
make sure the validation does not happen after the looping the generator
* add test to check all valid field value
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
Some tests which include function declarations designed to verify
behavior do not reference those functions. Insert the references
necessary for those functions to serve their intended purpose.
The `compareArray` utility function returns a boolean value describing
whether or not the input arrays are equivalent--it does not throw an
exception when invoked with non-equivalent arrays. Prior to this commit,
however, two tests invoked `compareArray` without inspecting its return
value, so it had no impact on the result of the test.
Update the tests to fail when the "expected" and "actual" arrays are not
equivalent.
There were a few tests already in the tree that overlapped ones that I
added in the previous commit. I've consolidated these and taken
information from the deleted ones where applicable, and improved on the
autogenerated assertion messages.
This reverts commit b690cb67be, reversing
changes made to 50dd431dff. This is
necessary because the reverted changeset reduced coverage by an unknown
extent.
While working on adding the Temporal tests from tc39/proposal-temporal I
noticed that these tests tested the same thing as each of the branding.js
tests in the same directory. This removes the duplicate tests.
Prior to this commit, a test for %TypedArray%.prototype.copyWithin
provided a TypedArray instance as the first argument. That argument that
is interpreted as a number, so in relying on the conversion, the test
verified behavior beyond what it purported to test.
Simplify the test by using the desired number value directly.
Prior to this commit, a number of tests used non-BigInt values where
BigInt value are commonly used. Although this was technically
permissible to validate the behavior under test, the atypical usage
patterns tended to obscure the tests' purpose. Replace with more
appropriate values.
Attempting to freeze the module namespace exotic object should not affect the `writable`-ity of the properties as that exercises the same `DefineOwnProperty` operation according to [`SetIntegrityLevel`](https://tc39.es/ecma262/#sec-setintegritylevel).
@erights discovered a [bug in v8](https://bugs.chromium.org/p/v8/issues/detail?id=12240) where, while the `Object.freeze` operation throws, it actually makes exported properties non-writable one by one.
At the request of @syg, I'm contributing a test against this behavior. The bug in v8 actually leads to a breakage of the objects invariants, however I'm not testing for that here as the root cause is the illegal freezing of the export.
Prior to this commit, a test for %TypedArray%.prototype.copyWithin
provided a TypedArray instance as the first argument. That argument that
is interpreted as a number, so in relying on the conversion, the test
verified behavior beyond what it purported to test.
Simplify the test by using the desired number value directly, and extend
the tests for type coercion to cover object values.
Following a recent normative change to the Resizable ArrayBuffer
proposal [1], the term "out of bounds" no longer applies to
"length-tracking" TypedArrays whose underlying ArrayBuffer has been
resized to match their byte offset.
Reflect this in the tests by renaming the condition from "out of bounds"
to "on boundary" and by adding new assertions for true "out of bounds"
conditions.
[1] https://github.com/tc39/proposal-resizablearraybuffer/pull/70
Ensure that when the ArrayBuffer of a length-tracking TypedArray is
resized to the address matching the TypedArray's byte offset, the
TypedArray is *not* considered "out of bounds."
Prior to this commit, the modified tests used the strict equality
operator to compare computed values with negative zero. Due to the
semantics of that operator, these tests would spuriously pass if the
value under test was in fact positive zero.
Update the tests to be more precise by instead asserting equality with
the `assert.sameValue` utility method (since that method correctly
distinguishes between negative zero and positive zero).
Prior to this commit, the modified test included two different
expressions in positions that were meant to describe the same
expression. This meant that the value of the intended expression was
only partially verified.
Correct the test to fully verify the value of the expression.
legendecas
Joseph Griego
Philip Chimento
Jesse Alama
Mike Pennisi
Justin Grant
Frank Yung-Fong Tang
Nicolò Ribaudo
rwaldron
Frank Tang
Nikhil Singhal
Sarah GHP
Ms2ger
André Bargull
Yusuke Suzuki
Rick Waldron
Leo Balter
Neil Dhar
Daniel Nalborczyk
Mathias Bynens
Phillip Mates
Philip Chimento
Mathieu Hofman
Andreas Woess
Richard Gibson