durationformat.format coverage #3510
Conversation
| "PT1H50M": { | ||
| "long": "1 hour and 50 minutes", | ||
| "short": "1 hr, 50 min", | ||
| "narrow": "1h 50m", |
There was a problem hiding this comment.
Not sure if hr or hr. and same with min vs min.
There was a problem hiding this comment.
Do we normally put the localized strings in the Test262 suite? Adding and removing . is a common thing that changes across CLDR updates
There was a problem hiding this comment.
There are some cases at relative time format :
I'm happy to only check the resolvedOptions of those methods instead avoiding depending on CLDR
There was a problem hiding this comment.
I was asking about the general policy of Test262 and CLDR-dependent output. I think it's useful to have at least a few tests for the expected output of the format function, but we just need to be aware that these tests are data-dependent, and the expectations could drift.
There was a problem hiding this comment.
This is what the locale key in the front matter is for
| "narrow": "2h 46m 40s", | ||
| "digital": "2:46:40", | ||
| }, | ||
| // Negative durations in Intl.DurationFormat https://github.com/tc39/proposal-intl-duration-format/issues/29 |
There was a problem hiding this comment.
Is the idea that these tests will be added later? From my reading of the issue, it says that tests should verify that the output is different between positive and negative. (Or should that be a separate test that isn't dependent on locale?)
In any case, I think the tests will currently fail as written because stylelist includes the keys that are missing from these objects? Maybe it's better to have something like
if (!(style in styletestData))
continue;| assert.throws(TypeError, () => { df.format(undefined) }); | ||
| assert.throws(TypeError, () => { df.format(-12) }); | ||
| assert.throws(TypeError, () => { df.format(-12n) }); | ||
| assert.throws(TypeError, () => { df.format(1) }); | ||
| assert.throws(TypeError, () => { df.format(2n) }); |
There was a problem hiding this comment.
Assuming tc39/proposal-intl-duration-format#92 gets merged, these will be RangeErrors because they will convert to a string which is not a valid ISO 8601 duration string.
I'd also suggest testing things like {}, null, true, and "bad string".
Co-authored-by: Philip Chimento <philip.chimento@gmail.com>
3bcb80c to
8c0c8a7
Compare
8c0c8a7 to
90f8254
Compare
Incremental coverage for DurationFormat.format
cc @FrankYFTang @ryzokuken @sffc