Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create testing plan for the Joint Iteration proposal. #4112

Open
ioannad opened this issue Jun 19, 2024 · 2 comments
Open

Create testing plan for the Joint Iteration proposal. #4112

ioannad opened this issue Jun 19, 2024 · 2 comments

Comments

@ioannad
Copy link
Contributor

ioannad commented Jun 19, 2024

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

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

@ioannad
Copy link
Contributor Author

ioannad commented Jun 20, 2024

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
Copy link
Contributor

bakkot commented Oct 15, 2024

A partial list of things that need testing, written with @michaelficarra . Stopped when we ran out of time, not when we ran out of things that need testing.

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
  • 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
  • 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.keys() is the same as they were on the first argument
  • tests with Symbol-named properties

both

  • 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
  • mode is not coerced to a string
  • 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 iterables are strings (after reading the padding)
  • 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
  • resulting iterator has [[Prototype]] of %IteratorHelperPrototype% (i.e., Object.getPrototypeOf(Iterator.from([]).take(0)))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants