Create testing plan for the Joint Iteration proposal.

[ioannad]

This is to plan and track the tests for the Joint Iteration proposal.

Proposal repo: https://github.com/tc39/proposal-joint-iteration

[ioannad]

I made a PR with a testing plan guide, still needs review but may contain useful information: https://github.com/tc39/test262/pull/4113/files

[bakkot]

A list of things that need testing, written with @michaelficarra . You might be able to think of more things but this is everything which occurred to us.

zip

• empty iterable as argument produces iterator which is finished
• cases for the iterable returned by padding:
  • it returns { done: true } in fewer steps than there are things to be zipped
    • in this case next should not be called any more times
    • and .return should not be looked at or called
  • it does not return { done: true } within the number of steps as there are things to be zipped
    • in this case its .return should be called after calling .next exactly the number of times as there are things to be zipped
• result objects are arrays

zipKeyed

• object with no own-enumerable keys as argument produces iterator which is finished
• confirm inherited keys are not used
• confirm non-enumerable keys are not used
• object with some iterable-valued properties and some undefined-value properties does not throw, produces result object with keys only for the iterable-valued properties
• make sure that output objects have correct attributes for the properties
  • output properties are writable/configurable, even if they were not on the input
• output objects inherit from null
• order of properties reported by Object.getOwnPropertyNames() is the same as they were on the first argument
• Symbol-named properties are included just like string-named properties
• output object is not an array (even if the input iterables object is an array)

both

• the usual boilerplate around name / length / enumerability / etc
• throws if the first argument is not an object (including if it is a string)
• throws if the second argument is not an object and not null/undefined
• mode is read from second argument
• throws if mode is not undefined and not a string, rather than coercing (including throwing for String objects)
• throws if mode is a string which is not one of the three legal values
• padding is read if and only if mode is "longest"
• when mode is "longest", throws if padding is not undefined and not an object (including if it is a string)
• mode is not read if the first argument is not an object
• throws if any to-be-zipped iterables are string primitives (after reading the padding)
  • throwing happens before reading any more items from iterables, after closing any already opened
  • String objects as to-be-zipped iterables work
• throws if any to-be-zipped iterables are not actually iterable (except the undefined special case for zipKeyed noted above)
• order of side effects in general (there are lots of these, just make something that makes every single side-effect observable and assert on the totality)
  • should assert immediately after calling .zip, and also after calling .next on the result
• can zip exactly one thing
• can zip exactly two things with the same number of elements
• can zip two iterable things of different length with no options object (which behaves like shortest)
  • need tests for first thing is longer, and second thing is longer
• as above but with each of the three modes explicitly
• when mode is strict, and the lengths are the same, once the first iterator completes .next on the rest, to check done-ness
• when mode is longest, correct padding is used
  • including with explicit padding for everything, with padding for some but not all things, and when padding is undefined
• as above but with three things
• output objects are "fresh", i.e., different identity for first vs second thing returned
• tests for closing the correct iterators in the various cases:
  • all the error cases (not going to enumerate these but there's a lot)
    • when the error is caused by one of the iterables breaking the iterator contract, that iterator is not closed
  • with "shortest" or "strict", after the shortest thing is exhausted
    • including when the shortest thing is in the middle of the list
  • when .return is called explicitly
  • including when mode is "longest" and some iterators have already finished (in which case they are not closed)
  • tests should assert that .return is invoked with the correct receiver
  • but don't close things which haven't yet been opened (i.e. Symbol.iterator invoked)
• resulting iterator has [[Prototype]] of %IteratorHelperPrototype% (i.e., Object.getPrototypeOf(Iterator.from([]).take(0)))