As originally written, this test would spuriously pass when the deleted
property was incorrectly visited by enumation but correctly removed from
the object. In such cases, the accumulator string would take the form
"aa1baundefinedca3"
And satisfy all conditions intended to highlight implementation errors.
Refactor the test to avoid false negative by using an object with a null
prototype and verifying the exact contents of the accumulator string.
As originally written, this test would spuriously pass when the deleted
property was incorrectly visited by enumation but correctly removed from
the object. In such cases, the accumulator string would take the form
"aa1baundefinedca3"
And satisfy all conditions intended to highlight implementation errors.
Refactor the test to avoid false negative by using an object with a null
prototype and verifying the exact contents of the accumulator string.
https://github.com/tc39/proposal-temporal/pull/2003 is a normative change
that reached consensus at the March 2022 TC39 plenary meeting. This adds
tests that verify the new spec text is implemented correctly, performing
arithmetic on a PlainYearMonth instance that would previously have thrown
an error if it was implemented as written.
https://github.com/tc39/proposal-temporal/pull/2090 is a normative change
that reached consensus at the March 2022 TC39 plenary meeting. This adds
tests that verify the change made to the formatting of years between 0 and
999 inclusive in all toString and toJSON methods of Temporal types that
can output an ISO year number in their return value.
(Philip, March 2022: This was originally Frank's PR #3057. I did some
reformatting, removed duplicate tests, addressed the review comments that
I left the first time around, and added some cases that I felt were not
yet complete.)
(Philip, March 2022: This was originally Frank's PR #3060. I did some
reformatting, removed a test that didn't exercise the whole feature, and
combined some duplicate tests with some existing tests.)
Where possible, observable calls originating from within Temporal, that
require an options argument, should pass `undefined` as that options
argument, rather than `{}` or `Object.create(null)`.
See tc39/proposal-temporal#1685.
I made a mistake with one of the signs in one of the time zones that we
use for verifying DST handling. Luckily this didn't affect any previously
existing tests, but it affected some new tests that I'm going to add in
the next commit.
How do I know that _this_ arithmetic is correct? I feel reasonably
confident with the added test.
These tests check API entry points that convert strings to
Temporal.PlainDate, with a list of various strings that are all not valid
for that context according to ISO 8601.
I'd like to add basic functionality tests for string arguments, and these
tests are testing something more specific: that a Get of the "overflow"
property on the passed-in options object is observable. Rename
accordingly.
* Create a Temporal.PlainDateTime with all arguments supplied.
Migrates some tests that currently exist in the
proposal-temporal repo.
* Check all data in Temporal.PlainDateTimes, variously constructed
Enrich existing tests to check all basic data in the
instance of `Temporal.PlainDateTime`, not just a single
field.
These additional checks were motivated by the migration of
existing Demitasse tests in the proposal-temporal repo to
test262. The Demitasse tests check more than a single
field.
Here's a test I should have included in #3395. It's allowed to replace the
"T" in the middle of an ISO string with a space, but not when the "T" is a
time designator prefix. This assertion ensures that implementations make
this distinction correctly.
There were three things wrong with the 'and', 'or', and 'nullish' tests
that I added as part of #2940:
1. They were in the wrong folder (should be
expressions/logical-assignment, not expressions/compound-assignment)
2. The tests for ||= and ??= on readonly accessor properties were
incorrect. These assignments would short-circuit if the getter
returned 1 as it previously did, so PutValue would not throw.
3. The tests for ||= and ??= on private methods were invalid, as a
method always evaluates to true in a boolean context, and is not
nullish, so these would always short-circuit.
I've removed the invalid private method cases, fixed the readonly
accessor cases, and added new templates to test the short-circuit
behaviour as well as the non-short-circuit behaviour.
Closes: #3413
This tests compound assignment, with each compound assignment operator,
to each kind of private reference (private field, private accessor
property with getter and setter, private accessor property with only
getter, and private method). The latter two cannot be assigned to and
therefore throw.
Closes: #2940
https://github.com/tc39/proposal-temporal/issues/1910 found a bug in an
indentation level of a line in the Temporal proposal, which affected the
outcome of the PreparePartialTemporalFields abstract operation. This adds
tests for all entry points that use that abstract operation, to make sure
the behaviour is correct: only defined properties are copied in with()
methods.
This was a normative change that achieved consensus at the December 2021
TC39 meeting.
https://github.com/tc39/proposal-temporal/pull/1956 clarified that the
fractionalSecondDigits and smallestUnit options to
Temporal.Duration.p.toString() specified the exact number of digits after
the decimal point, no more and no less.
This was a normative change that achieved consensus at the December 2021
TC39 meeting.
https://github.com/tc39/proposal-temporal/pull/1952 added support for time
designator prefixes in PlainTime strings. This adds three tests to all
entry points that convert an ISO string to a PlainTime:
- no-implicit-midnight: ISO strings with only a date and no time are no
longer accepted. Previously they were implicitly interpreted as 00:00.
- with-time-designator: Tests that various forms of string with time
designator are correctly parsed.
- time-designator-required-for-disambiguation: Tests various cases where
a string without a time designator is ambiguous and therefore the time
designator is required, as well as various cases that implementations
might assume are ambiguous but in fact are not.
This was a normative change that achieved consensus at the December 2021
TC39 meeting.
https://github.com/tc39/proposal-temporal/pull/1907 was a bug that caused
negative Duration strings with fractional units to be rounded incorrectly.
Add tests that ensure the rounding mode is correct.
This was a normative change that achieved consensus at the December 2021
TC39 meeting.
A follow up to the previous commit, this rewrites some tests that relied
on the lack of brand checks for certain Temporal.TimeZone methods.
https://github.com/tc39/proposal-temporal/pull/1693 added brand checks to
these methods.
We can no longer use a plain object time zone or even a Proxy with a real
branded Temporal.TimeZone object as its handler to do these tests, so we
instead create an instance of Temporal.TimeZone and define own accessor
properties on it in order to test the observable property accesses that we
need to see according to the spec text.
This requires an improvement to TemporalHelpers.observeProperty() in order
to be able to log property accesses to Symbol-valued properties.
https://github.com/tc39/proposal-temporal/pull/1693 added checks for the
receiver of certain Temporal.Calendar and Temporal.TimeZone methods. Add
branding tests for these methods, similar to the already existing branding
tests.
This was a normative change that achieved consensus at the December 2021
TC39 meeting.
These tests already existed for PlainDate. Copy them to the other types
(and use the constructor instead of from() in order to be as simple as
possible)
I forgot to add these to PlainDate, testing what happens when we pass
undefined as the value for the largestUnit option. Similar tests already
exist for the other types.
Some of these (in PlainDate) had already been rewritten to test more
invalid strings that are otherwise valid units. This commit takes these
improvements and brings them to all of the similar tests for other types'
since() and until() methods.
https://github.com/tc39/proposal-temporal/issues/1753 records the
consensus reached at the October 2021 TC39 meeting to disallow "-000000"
as an extended year, both in Date.parse and Temporal. This adds tests for
the Temporal part of that.
https://github.com/tc39/proposal-temporal/pull/1893 was a bug that caused
the 'offset' property to be ignored in ZonedDateTime property bags. Add
tests that ensure it is not ignored.
This was a normative change that achieved consensus at the October 2021
TC39 meeting.
https://github.com/tc39/proposal-temporal/pull/1780 fixed a typo in the
UnbalanceDurationRelative abstract operation, which should affect the
entry points tested here.
This was a normative change that achieved consensus at the October 2021
TC39 meeting.
There were two cases where tests in intl402/ had some duplication of tests
that are in built-ins/ as well. Remove this duplication, and restrict the
intl402/ tests to testing things that can't be tested on all hosts.
For cases in the previous commit that actually removed some functionality
from tests in built-ins/, add corresponding tests in intl402/ to preserve
test coverage of that functionality for hosts that do support Intl.
This requires a few adjustments of time zone names and offsets in some
places. The only named time zone that is required to be supported by an
implementation not supporting ECMA-402 is "UTC".
After Intl.NumberFormat v3, default useGrouping is "auto".
We also fix test/intl402/NumberFormat/test-option-useGrouping.js. After v3,
it accepts string and boolean.
The phase field must precede the type field for negative tests
to have a consistent style and be able to parse easier.
Related to the goal of https://github.com/tc39/test262/issues/1997
Added this check to the linting script and updated tests accordingly.
We need to set minimumFractionDigits: 1 for the case of {roundingIncrement: 5, maximumFractionDigits: 1} and also adjust the test expectation.
Otherwise, inside testNumberFormat , it will call getPatternParts to format 1.1 and -1.1 and cause pattern mismatch (because the result will be "1" instead of "1.1" in that configuration)
https://github.com/tc39/test262/blob/main/harness/testIntl.js#L2369
Includes key should use flow notation to be able parsed easier
as suggested in https://github.com/tc39/test262/issues/1997
Added this check to the linting script and updated tests accordingly.
Prior to this patch, the tests for certain Array prototype methods
incorrectly expected all elements to be "visited" even when a given
property was not present according to HasProperty.
Update the tests to reflect the fact that under such conditions, the
removed element is not visited.
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 ":"