new Void() in Java

??? The Java equivalent is null, like in C# and Javascript. The Void type in Java has no public constructor, so you can't call new Void() and you can't return an instance of Void. It's just there to represent the void keyword as something you can interact with.

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)

In the execution I copy+pasted the header + log from for the wrong result, it was expecting false, which would have been correct for the arguments it was supposed to be passing according to the header. My function returned true, which was correct for the actual arguments it was given. Even if you don't get it to fail, you can see the arguments it's supposed to pass and the arguments it actually passes are different if you print the arguments.

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.

Doing it in Typescript. The first random test consistently (EDIT: semi-consistently) fails and, going by console.log calls, it looks like it's because it's asserting the result of one set of inputs while actually calling the function with a different set.

Where my solution begins with:

export function comp(a: number[] | null, b: number[] | null): boolean
{
    if(a == null || b == null || a.length != b.length)
        return false;
    
    console.log("");
    console.log("a: " + a);
    console.log("b: " + b);
    console.log("");
    ...
}

The first random test fails with expected true to equal false, where the first random test's header reads: (wrapped for readability)

Testing for [26, 92, 76, 29, 46, 74, 16, 55, 22, 28, 92, 10, 99, 5, 73, 94, 16, 27, 7, 2, 94]
and [676, 8464, 5776, 841, 2116, 5476, 256, 3025, 484, 784, 8464, 100, 9801, 25, 5329, 8836, 256, 729, 49, 4, 8836]

but the console log reads:

a: 52,26,2,66,16,91,52,13,18,100,54,47,35,82,89
b: 2704,676,4,4356,256,8281,2704,169,324,10000,2916,2209,1225,6724,7921

Every other test passes with my current solution.

EDIT: Looking at the logs of the rest of the random tests, regardless of what the test header says they're testing, they all (except the first) have the log output:

a: 0,1,1,2,4,10,15,32,39,60,63,67,77,78,85,86,93
b: 0,1,1,4,16,100,225,1024,1521,3600,3969,4489,5929,6084,7225,7396,8649

The Swift tests are still broken.

The sample tests fail by themselves independent of the solution code: https://i.imgur.com/qwh8jTm.png

The "attempt" random tests expect the wrong results for "8.2M ohms" ( https://i.imgur.com/21Xarxu.png ) and "4.1M ohms". ( https://i.imgur.com/ppBHn61.png )

I did not mean to submit that ~_~ I was trying to get the "attempt" random tests to test with "8.2M ohms", which seems to test for the wrong answer. (At least in the Swift version)

Ah. I completed it for Swift. The tests given for swift require a different format from the tests for every other language.

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