They are inconsistent for my solution because I do a lot of work. So those 200x200 grids take a lot more time than smaller ones ( quadratics come into play ).

Times for my solution vary from 7 seconds to time-out. ( My solution is currently invalidated. Its results are correct, it's still incorrectly failed on the non-square tests, but it does time out sometimes. )

My favourite trick for generating random tests is sizing them gradually ascending, which gives solvers smaller random tests early on, and fewer large ones ( which can only happen later ), without having to have separate blocks. Just scale the index counter to max size.

Oh, Multiple Different Answers Are Possible is still missing "1 occurs more than once in column 4" here:

// copy5 => [[1, 2, 1, 1], [5, 2, 3, 4], [4, 3, 2, 1, 0], [2, 1, 4, 3]]
runTest(copy5, 4, ["Array not square","1 occurs more than once in row 1","2 occurs more than once in column 2","5 at 2,1 is not between 1 and 4","0 at 3,5 is not between 1 and 4"]);

Did I say this was in column 3 ?!?

I might have been the first clown in a year and a half to randomise answers. My solution sometimes times out because it collects everything; it's a lot easier to pass returning as soon as possible.

Instead of fixed answers, a validator would be nice, but it's practically impossible to supply one in Preloaded and not give the game away.

The way later fixed tests accept multiple answers is probably the way to go.

Some of the later fixed tests accept multiple answers. The same things could be done for these tests; they primarily test for unsquare inputs, but according to the specs, they have to accept the other answers as well.

Looking back on it, this kata was over-ambitious. I thought it would be interesting to create a kata out of validating another one, but I'm not sure it was a good idea.

I didn't do the JS translation, so it's not easy to change this. (They don't seem that inconsistent to me. They are more consistent than the Python runtimes, which seem to range between 3 - 6 secs.)

I'm not sure these can be easily fixed. For example, if one row of the square is longer than it should be, either it will have duplicates or numbers outside the range.

Maybe the "Not Square" tests should be removed?

I believe these are fixed (in both Python and JS).

( JS )

Random tests runtimes vary wildly. Try to generate more consistently distributed sizes.

( JS )

    square = [[1, 3, 2, 3], [3, 1, 4, 2], [1, 4, 3, 3], [1, 2, 4, 3]];
    messages = ["3 occurs more than once in row 1", "3 occurs more than once in row 3", "3 occurs more than once in column 4", "1 occurs more than once in column 1"];

This example test ( Repeating Value ) is missing "4 occurs more than once in column 3".

    const square = [[1, 2, 3], [2, 3, 1], [2, 4, 1, 3]];
    const messages = ["2 occurs more than once in column 1", "4 at 2,3 is not between 1 and 3", "Array not square"];

This example test ( Multiple Different Answers ) is missing "1 occurs more than once in column 3", and the 4 is at 3,2, not 2,3.

Looks like the fixed submit tests make exactly the same mistakes. The random tests don't complain.

( JS, possibly others )

The Not Square example tests also have repeating numbers. If my solution complains about those repeating numbers, it gets shot down for not complaining about not being square.

I don't know if the submit tests do the same thing ( not that far yet ), but the example tests should implement the specifications, which explicitly state my solution can choose between not square and repeated number.

ETA: Looks like the fixed submit tests make exactly the same mistakes. The random tests don't complain.

Approved - Thanks!

Slight (visual) updates to the description - feel free to approve:
https://www.codewars.com/kumite/66fd016a46074ccb4264c3b6?sel=66fd016a46074ccb4264c3b6

me to :')