Except when Void is a class that has already been defined in the preloaded section...

Other way around: All the assertions were the same. The it descriptions were correct.
Putting everything in the same function fixes that, they're all cozying up in the same it but whatever I guess. That works.

the it description is not what is being asserted.

Right, all tests are different but "it" description is wrong.
Modified the random tests for "it" and used copies to avoid mutation effects.
If you have time maybe you could have a look and re-raise an issue if needed.

Additionally, as mentioned above, input can be mutated to affect what the reference receives. (Which is likely to happen considering that array.sort mutates)

one could also argue that fixed tests shouldn't share an it and should show what the input is. depends on whether one expects the user to printf debug or not.

@g964 no, you're wrong. the it description is not what is being asserted.

@ChrisMassie: I can see your solution and I tried it; it has always passed, many times, but maybe I didn't see and try your first version... I suppose the input was mutated somewhere. Nevertheless I will modify this part assert.strictEqual(comp(a1, a2), reference(a1, a2));.

@natan:

the callback runs 100 times after the loop, all with the same a1 and a2

You are wrong the inputs are never the same. For example here are the first two random tests of a try:

Testing for [72, 21, 80, 5, 36, 72, 13, 67, 97, 86, 59, 17, 69, 50, 33, 4, 27, 61, 75, 100, 62] and [5184, 441, 6400, 25, 1296, 5184, 169, 4489, 9409, 7396, 3481, 289, 4761, 2500, 1089, 16, 729, 3721, 5625, 10000, 3844]
Testing for [28, 30, 74, 13, 52, 43, 91, 9, 91, 45, 37, 73] and [784, 900, 5476, 169, 2704, 1849, 8281, 81, 8281, 2025, 1369, 5329]
...
...

Nah it expects based on what it sends you, not based on the header, which suggests that you truly did fail that test.

    it("Testing for ["+a1.join(", ")+"] and ["+a2.join(", ")+"]", function() {
        assert.strictEqual(comp(a1, a2), reference(a1, a2));
    });

the header runs immediately, which is why they print the correct test cases. the callback runs 100 times after the loop, all with the same a1 and a2. both the reference and your solution are receiving the same input, so the expectation will be correct for that one case which is repeated 100 times. maybe you mutate input, which would make the reference get different input (that's also something that needs to be fixed, the reference should run first, or use a copy, or mutation should be detected)

Yeah, the tests don't use closures correctly, capturing variables instead of values and therefore run the last testcase 100 times (the other 99 don't get tested)
This could be fixed by wrapping it in a function like so:

((a1, a2) => {
    it ( ... ) ...
})(a1, a2)

That doesn't explain how you fail the assertion though, or why it expects false. The reference solution gives true for the input you printed (as it should). Maybe your solution is wrong, but I can't tell without being able to reproduce and make my own observations.

@ChrisMassie: which language? You are right: it can depends on the language. You see that in "Sample Tests".

No, as proved by the string you provide...

Even if there is an instance when there is division by number it should never return infinity. Lets say we examine the limit of 1/x as it approaches 0. As we approach 0 from the right we will get positive infinity but as we approach 0 from the left we get negative infinity. Thus, as we approach 0 we get two different sets of answers and we cannot return infinity. Furthermore, the solution set as we approach 0 contains numbers of ever increasing or decreasing values. So, returning Not a Number is not a valid return. Therefore, the only value that a 0 divisor should return is undefined.

Really makes you think...

This is why overwriting built-ins is considered a bad practice...

Fixed (divisor will not be 0 anymore)