Any ideas on testing ToLength behavior?

[domenic]

In ES6, array methods can operate on lengths up to 2^53 - 1, instead of 2^32 - 1. This makes writing tests hard. Consider:

if (Array.prototype.contains.call({ length: +Infinity }, 'a') !== false) {
    $ERROR('Expected { length: +Infinity } to not contain \'a\'');
}

var arrayLikeWithTrap = {
    length: +Infinity,
    get 9007199254740992() {
        $ERROR('Getter for 9007199254740992 (i.e. 2^53) was called');
    },
    '9007199254740993': 'a'
};

if (Array.prototype.contains.call(arrayLikeWithTrap, 'a') !== false) {
    $ERROR('Expected trapped array-like with length 9007199254740992 to not contain \'a\'');
}

var arrayLikeWithTooBigLength = {
    length: 9007199254740995,
    '9007199254740992': 'a'
};

if (Array.prototype.contains.call(arrayLikeWithTooBigLength, 'a') !== false) {
    $ERROR('Expected array-like with too-big length to not contain \'a\', since it is beyond the max length');
}

all of these tests will likely take longer than the age of the universe to complete, since they are testing an algorithm that takes 2^53 iterations to reach the case we care about.

I'd be curious about other strategies I should employ instead?

[anba]

I wonder if it is okay to use the fromIndex parameter to restrict the search space in this case? Obviously that's not a general solution, but at least it should help for Array.prototype.contains....

[domenic]

That'll do the trick for my case! Leaving open in case anyone wants to discuss other scenarios; or repo owners can close if they'd rather keep the issues list clean.

[leobalter]

We already test the boundaries for length in many built-in api cases, including [].includes. I think this would entirely be fixed in a major refactoring of several test for the built-in parts, with a big clean up of legacy tests.

repo owners can close if they'd rather keep the issues list clean.

:) not because of this specific reason, but not a bad motivation as well.