As of https://github.com/tc39/proposal-temporal/pull/2219 since() and
until() methods should be calling the calendar's dateUntil() method with a
null-prototype object as the options parameter, due to the change in
MergeLargestUnitOption. This adds a test for this behaviour.
Each from() method except Calendar and TimeZone should test that when you
pass an instance of that type, the return value is a clone of that
instance, and a distinct object.
These tests existed already for some types; regularize them and add the
ones that didn't exist yet.
In order to test the referenceISODay of a PlainYearMonth we add an
argument to TemporalHelpers.assertPlainYearMonth.
Of the toString() methods that have options for printing a time with
seconds and fractional seconds, PlainTime seems to have the most
comprehensive set of tests. Bring all the others (Duration, Instant,
PlainDateTime, and ZonedDateTime) in sync with PlainTime, and edit the
PlainTime ones where necessary to include improvements from the others.
Tests:
- fractionalseconddigits-invalid-string.js: copy and expand on
PlainTime's more comprehensive set of invalid strings. Add assertion
message. Fix front matter.
- fractionalseconddigits-non-integer.js: Fix front matter.
- fractionalseconddigits-out-of-range.js: make sure infinity is tested.
Add assertion messages. Fix front matter.
- fractionalseconddigits-undefined.js: copy PlainTime's more
comprehensive test with whole minutes, whole seconds, and subseconds.
Copy PlainTime's test of an empty function object. Add more
descriptive variable names and assertion messages. Fix front matter.
- fractionalseconddigits-wrong-type.js: inline and delete TemporalHelper
used here; it was only good for this test anyway. Improve assertion
messages.
- smallestunit-valid-units.js: copy PlainTime's test with a second value
with zero seconds even. Refactor repetitive tests into a loop. Copy
the invalid unit "era" from the Instant test. Add assertion messages.
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.
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.
I used kind of misleading parameter names in this function, they are not
"one" and "two" of the same thing, but a Temporal.PlainDate and a
Temporal.Duration.
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.
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.
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
This reverts commit b690cb67be, reversing
changes made to 50dd431dff. This is
necessary because the reverted changeset reduced coverage by an unknown
extent.
* Temporal.now.plainDateTime: import tests from prop
* Add required metadata
* Correct invalid test
Ensure the error is thrown due to the invocation of the provided method.
Add a separate test to verify how the method is invoked.
* Remove duplicated assertions
* Improve coverage
* Rewrite test to focus on Calendar parameter
The observable interactions with the "timeZone" parameter are verified
by another test which is named for that purpose.
* Remove non-standard test
This test's title suggests that it was intended to verify the behavior
when the "calendar" parameter was undefined. The expected behavior in
that case depends on the presence of a builtin calendar named
"undefined." Test262 cannot definitively assert the presence or absence
of such a calendar.
In contrast to the title, the test body actually uses the calendar name
"japanese." Test262 cannot definitively assert the presence or absence
of such a calendar.
* Fix test for only {localeMatcher: "lookup"}
The expectation that "sr-Thai-RS" would be returned is only true with the
9.2.2 BestAvailableLocale ( availableLocales, locale )
https://tc39.es/ecma402/#sec-bestavailablelocale
algorithm used by 9.2.3 LookupMatcher ( availableLocales, requestedLocales )
https://tc39.es/ecma402/#sec-lookupmatcher
The default for localeMatcher is "best fit" but not "lookup" for all Intl objects.
And for 9.2.4 BestFitMatcher ( availableLocales, requestedLocales )
https://tc39.es/ecma402/#sec-bestfitmatcher
It may not match "sr-Thai-RS" for "sr" and return ["de", "zh-CN"] instead. Therefore, we need to change this test to only test on {localeMatcher: "lookup"}
* Add option to getLocaleSupportInfo
Needed to test different localeMatcher
* only test for "lookup" localeMatcher
* Get the info based on the localeMatcher
* pass in localeMatcher to getLocaleSupportInfo
This code is setting values to $1 etc., which can be non-writable or accessors.
For example, https://github.com/tc39/proposal-regexp-legacy-features/ is specifying them as accessors, and they should throw an error when
it is done in strict code. We should execute `(/(?:)/).test("");` to clear them.
The WeakRefs proposal advanced to Stage 4 but cleanupSome moved back to a Stage 2 status.
The tests should remain in Test262 for now but this feature flag should help users to
filter tests out.
Verify that every test file which references a harness file using the
"includes" directive also contains at least one reference to a value
defined in the harness file.
To support this check, extend each harness file with a list of values
which it defines.
* Introduce `assert._toString`
* Use `assert._toString` in `assert`
* Use `assert._toString` in `assert.sameValue`
* Use `assert._toString` in `assert.notSameValue`
This test started failing when updating to ICU 64, because ICU supports "zh"
and "zh-Hans-CN", but not explicitly also "zh-Hans", which is required for this
test to pass. The same kind of error is reproducible with ICU <64 when "Guru"
is added to the list of script codes in 'testIntl.js', because ICU supports
"pa-Guru-IN", but "pa-IN" isn't explicitly supported, too.
So, change this test to also check 'byFallback' to see if a locale is supported.
Drive-by change:
- Modernise the test to make it more readable how subtags are combined.
- Also add "419" to the list of region codes to cover the digit region syntax.
harness/testIntl.js
- Add now invalid tags to getInvalidLanguageTags, these tags were previously used in test files changed in this commit.
- Update isCanonicalizedStructurallyValidLanguageTag regular expressions.
test/intl402/Intl/getCanonicalLocales/canonicalized-tags.js
- Moved five now invalid tags to getInvalidLanguageTags function in testIntl.js
test/intl402/Intl/getCanonicalLocales/preferred-grandfathered.js
- All irregular grandfathered tags are invalid now
- Regular grandfathered with extlang subtags are now also invalid
- Regular grandfathered with variant-like subtags are still valid
test/intl402/Intl/getCanonicalLocales/weird-cases.js
- Revert changes from last commit
- "x-u-foo" is now invalid and was moved to getInvalidLanguageTags function
test/intl402/ListFormat/constructor/constructor/locales-valid.js
test/intl402/RelativeTimeFormat/constructor/constructor/locales-valid.js
test/intl402/Segmenter/constructor/constructor/locales-valid.js
- Irregular grandfathered and privateuse only are no longer valid language tags
test/intl402/language-tags-canonicalized.js
- Same changes as in test/intl402/Intl/getCanonicalLocales/canonicalized-tags.js
test/intl402/language-tags-invalid.js
- Invalid tags list in this file was a subset of getInvalidLanguageTags, so replaced with getInvalidLanguageTags to get more coverage
test/intl402/language-tags-valid.js
- Same changes as in test/intl402/Intl/getCanonicalLocales/canonicalized-tags.js
Migrating all tests to this API is necessary to prevent tests from hanging indefinitely when a SAB is sent to a worker but the code in the worker attempts to create a non-sharable TypedArray (something that is not Int32Array or BigInt64Array). When that scenario occurs, an exception is thrown and the agent worker can no longer communicate with any other threads that control the SAB. If the main thread happens to be spinning in the $262.agent.waitUntil() while loop, it will never meet its termination condition and the test will hang indefinitely.
Because we've defined $262.agent.broadcast(SAB) in https://github.com/tc39/test262/blob/master/INTERPRETING.md, there are host implementations that assume compatibility, which must be maintained.
Philip Chimento
Romulo Cintra
Ms2ger
Mathias Bynens
Mike Pennisi
Philip Chimento
Rick Waldron
rwaldron
Leo Balter
André Bargull
Frank Yung-Fong Tang
Paul Bakker
Linus Groh
Yusuke Suzuki
Alexey Shvayka
Richard Gibson
Gus Caplan
Frank Tang
Ross Kirsling
Shu-yu Guo
Daniel Ehrenberg
Ron Buckton
Ms2ger