Temporal: Reorganize calendar and wrong-type tests

[brageh01]

Changes made to:

• PlainDate
• PlainYearMonth
• ZonedDateTime
• PlainDateTime
• PlainMonthDay

Merged calendar-number.js and calendar-wrong-type.js, due to no special behaviour of number to be tested.

Extracted string tests to calendar-iso-string.js and renamed the file to calendar-invalid-iso-string.js, due to the contents of the file initially testing invalid ISO strings.

Questions:

Are change to be made for the argument-propertybag-calendar-number.js and argument-propertybag-calendar-wrong-type.js files as well?
However, I notice that the argument-propertybag-calendar-iso-string.js actually tests for valid and not invalid ISO strings here. Perhaps create a invalid-iso-string.js?

Is the "merge-and-extract» also relevant for relativeto-propertybag-calendar-number.js and relativeto-propertybag-calendar-wrong-type.js?

[sffc]

Issue: #3873

[sffc]

About the questions: my sense is that the propertybag tests are probably also in scope to be refactored here in a similar way.

[ptomato]

Thanks! It looks like this is on the right track. There may be some tests still left to do. For example, there should be relativeto-propertybag-... tests in Duration/prototype/round/ and Duration/compare/ as well, and I think there are a lot more argument-propertybag-... tests; there should be some for every API entry point that takes a Temporal object, for example withPlainTime methods.

Feel free to use a script to automate a first draft of changes if there are a lot of files to do.

To answer your questions:

Are change to be made for the argument-propertybag-calendar-number.js and argument-propertybag-calendar-wrong-type.js files as well?

Yes please.

However, I notice that the argument-propertybag-calendar-iso-string.js actually tests for valid and not invalid ISO strings here. Perhaps create a invalid-iso-string.js?

That sounds correct.

Is the "merge-and-extract» also relevant for relativeto-propertybag-calendar-number.js and relativeto-propertybag-calendar-wrong-type.js?

Yes.

[ptomato]

I see you found a pre-existing error in this test, we forgot the time zone. Thanks!

(Well, technically it's not an error; in step 4.b-c of ToTemporalZonedDateTime the check for a faulty calendar occurs before the check for a missing time zone. So the test was still correct, but it was testing something different than I expected.)

Normally I would suggest that we should make a separate test file to ensure that the "faulty calendar" exception is thrown before the "missing time zone" exception, but in this case I think no further action is needed. We generally don't test that sort of thing anyway currently. (See also #2746 for a draft of how we might test it in the future.)

[ptomato]

One more thing I forgot... please take a look at the indentation. We don't generally enforce particular coding style or indentation choices, but there are some files in this draft where the indentation is a mix of 2 and 4 spaces and we should try to avoid that.