I overlooked the fact that passing an imported module object to $DONE will
correctly fail the test.
I still think this way of writing the test is unclear, though.
This proposes a `harness/asyncHelpers.js` file with two helpers in it,
`asyncTest()` and `assert.throwsAsync()`. See the RFC for further
motivation and details.
Note the draft RFC process in https://github.com/tc39/test262/pull/3525.
My idea for this pull request is that besides being an RFC in its own
right, we use it as a test case for the process. That is, we follow the
draft RFC process and hopefully either validate it, or surface changes
that need to be made, after which we can land the RFC process in our
documentation.
Following up on #3751 and #3762, this commit makes a few tests
work on both CLDR 42 and CLDR 41. Previously these tests were
tied to a specific CLDR 42 format.
Adapt to the following changes in CLDR 42 in Node 19:
- Some spaces in formats replaced by other whitespace unicode characters
- German format changes, which may be bugs (see
https://unicode-org.atlassian.net/browse/CLDR-16243)
This commit makes affected tests more resilient to Intl.DTF output
changes between Node versions.
A good idea for a future PR would be to change these tests to rely less
on CLDR formats while still testing that Temporal and Intl are behaving
as expected.
Here are some of the standard tests for property metadata of the
Array.fromAsync property and for the built-in function object. These don't
require doing anything asynchronously, so can be considered separately
from the Async Helpers RFC.
* Reject exceptional input to `isConstructor`
Prior to this commit, the `isConstructor` harness function would return
`false` when invoked with a value that lacked a [[Call]] internal
method. While it's true that such values are not constructors, there are
no tests which benefit from using `isConstructor` to make such an
assertion.
Extend `isConstructor` to throw an error when invoked with a
non-function object. Update a test which was misleadingly invoking the
function with the value `undefined`.
* fixup! Reject exceptional input to `isConstructor`
This contains tests for the normative PR
https://github.com/tc39/proposal-temporal/pull/2437, which is to be
presented for consensus to TC39 in the upcoming plenary meeting. That PR
changes the observable order of property accesses to be alphabetical where
possible.
1. String.prototype.toWellFormed's name is "toWellFormed".
2. "asserts" does not exist in the test harness, and "assert.throws"
expects the error type first.
This reconciles changes made in two normative PRs to the Temporal proposal
which each had their own separate PRs for tests. The yearOfWeek tests were
written before the changes to the ISO 8601 grammar which disallowed the
YYYY-MM-DD+UU format. This brings the yearOfWeek tests in line with the
tests for the other calendar methods.
This test template shared the same "path" as its sibling,
cls-decl-decorators-valid-syntax.template. That meant that these two
templates would race to generate the same test files with different
contents.
This prefixes the generated tests for class element decorators (as opposed
to class decorators) with "class-element-".
While we're at it, use assert() instead of assert.sameValue() for brevity,
if we are not specifically testing that the return value of hasOwnProperty
is the value true or false; and add more informative assertion messages to
help with debugging.
In some cases, the Object.hasOwnProperty.call could be replaced with
verifyProperty(), if the property descriptor was also being verified at
the same time.
This fixes some tests that were faulty to begin with: a common mistake was
Object.hasOwnProperty(obj, prop) which is probably going to return false
when that's not what you want.
The only instances left of `Object.hasOwnProperty` are one regression test
in implementation-contributed which I can't tell if it was intentionally
needed to trigger the regression, and a few instances of
`Object.hasOwnProperty('prototype')` which would defeat the purpose to
convert into `Object.prototype.hasOwnProperty.call(Object, 'prototype')`
form.
Closes: #3524
As per the discussion in
https://github.com/tc39/proposal-temporal/issues/2379#issuecomment-1248557100
and the PR https://github.com/tc39/proposal-temporal/pull/2398, which is
to be presented for consensus to TC39 in the upcoming plenary meeting, UTC
offsets and the Z designator should be disallowed after any date-only
strings (YYYY-MM-DD, YYYY-MM, and MM-DD). They should only be allowed to
follow a time component. Z remains disallowed in any string being parsed
into a Plain type.
Annotations become allowed after any ISO string, even YYYY-MM and MM-DD
where they were previously disallowed.
To be presented for consensus in the November/December TC39 meeting. This
adds tests for a 'yearOfWeek' getter to PlainDate, PlainDateTime, and
ZonedDateTime, for use alongside 'weekOfYear', and tests for a
corresponding method to Calendar.
The tests are basically the existing tests of 'weekOfYear' adapted.
Temporal issue: https://github.com/tc39/proposal-temporal/issues/2405
This contains tests for the normative PR
https://github.com/tc39/proposal-temporal/pull/2433, which is to be
presented for consensus to TC39 in the upcoming plenary meeting. That PR
changes ToTemporalCalendar to throw when it encounters a Temporal.TimeZone
instance, and ToTemporalTimeZone to throw when it encounters a
Temporal.Calendar instance.
The Python 2 and 3 jobs run essentially the same thing twice. I asked for
a sign from implementations if any of them were relying on Python 2 for
their test262 runners, but didn't hear of any that were.
The Python tools are changed so rarely that I think it's OK to drop this
CI job. If a future change breaks Python 2 for someone, we can accept PRs
to fix it on a best-effort basis, or reinstate this CI job if it's really
necessary.
Closes: #3480
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
Co-authored-by: Ms2ger <Ms2ger@gmail.com>
We already have a similar test covering TimeZone.id that ensures toString
is not called. We did not have this coverage yet for Calendar.id, so adapt
the TimeZone test for Calendar.
This adds order-of-operations tests that cover all of the Temporal entry
points that accept options bags, that were not already covered. We'll be
using these tests in the future to verify
https://github.com/tc39/proposal-temporal/issues/2254
However, the tests in this commit reflect the current state of the
proposal, not the potential normative change.
Some of the existing order-of-operations tests didn't observe the calendar
operations. Add a TemporalHelpers.calendarObserver() calendar to the
invocations of these methods in the order-of-operations tests.
Philip Chimento
Cam
Cam Tenny
Justin Grant
Aditi
Ms2ger
Huáng Jùnliàng
snek
jugglinmike
Frank Yung-Fong Tang
Timothy Flynn
Richard Gibson
Jordan Harband
André Bargull