tests for Iterator.prototype.join - #4768
Conversation
| Iterator.prototype.join.call(it, throwy); | ||
| }); | ||
|
|
||
| assert.sameValue(gotNext, false); |
There was a problem hiding this comment.
| assert.sameValue(gotNext, false); | |
| assert(!gotNext); |
?
There was a problem hiding this comment.
Arguably this is more readable in terms of the failures you get. Certainly it is not worse. In any case I don't think it's worth changing.
| var coercible = { | ||
| toString: function () { | ||
| if (called) { | ||
| throw new Test262Error('toString should be called exactly once'); |
There was a problem hiding this comment.
To assert exactly-once behaviour, I would just use a counter and assert on the counter at the end.
There was a problem hiding this comment.
That is also a valid way to do it but I'm happy with this as-is.
These are from tc39/test262#4768 which is currently under review. Once the tests land upstream, these can be removed. This will be handled as part of shipping the feature when it reaches Stage 3. Differential Revision: https://phabricator.services.mozilla.com/D296726
ptomato
left a comment
There was a problem hiding this comment.
These look good, let's merge them in any case.
There's one remaining item from the testing plan #4697 that I don't think is covered in this PR: ".next is looked up only after toString'ing the separator".
I hadn't read the testing plan too carefully until now, but it seems fairly complete to me. It occurred to me that you could test the following two things:
- iterator with
get next() { throw new Test262Error() } - iterator with
get return() { throw new Test262Error() }
...these cases would exercise code paths in implementations that these tests don't yet exercise, but I don't think they'd produce observably different results than the test cases you've already got, so it's debatable whether these two cases are meaningful.
|
|
Fixes #4697.
Tested against a polyfill.