Oh makes sense. Either case the random tests guarantee both odd and even lengths

Parity can be relevant for solutions which try to process the input in chunks of 2 elements and risk miscalculating the end, skip the last element or run into out of bounds access.

or maybe solutions which try to split some array in half and get it wrong on odd lengths.

JavaScript Translation. Modifies the description to make it language agnostic.

• Side note: unless I'm missing something, the Python tests seem to care about the parity of the array length - isn't that an irrelevant attribute? The ratio of negatives to positives is, imo, the key attribute. The parity affects nothing - you're not dividing by 2. So for the fixed tests, I did not group things by parity like the Python version.

Approved

python new test framework is required. updated in this fork

Nice!

Done. Thanks!

Should be fixed by now. Thanks!

Adapted the description to include "non-negative" values and fixed test cases. Thanks!

input is vulnerable to mutation, in the random tests

Your tests never include duplicate values. Better test that as well.

yes, expected and actual are effectively swapped in the random tests. And 0 can show up from time to time in some of those.

that would depend on who you are talking too, unfortunately. That's why it should be told plainly in the description.

Zero isn't positive or negative and shouldn't be "considered" as such. The judge solution uses >= 0, so the kata should say "non-negative" instead of "positive".

Ah, I forgot one important edge case: what about 0? => you have to tell if you considere it positive or negative (positive, looking at your solution) and put some tests with it. Note that your random tests may not generate any zero, otherwise, ZED's solution would never have passed.