How is this best practice?

Why would adding a fixed test not be a solution? Of course you can calculate the probability that this edge case is generated by random tests and then add enough random tests to guarantee a 99.9% chance of covering the edge case, but honestly just adding a fixed test and calling it a day seems like the reasonable solution here.

According to the codewars docs, this is exactly what fixed tests are for: https://docs.codewars.com/authoring/guidelines/submission-tests/#fixed-tests

Your solution being buggy and needing a special check to pass the tests is not a kata issue

I may not have been clear. My solution passes even though it is wrong because the tests dont verify all cases. It does not need extra checks to pass. There should be extra tests because it shouldn't pass. At least that's the point of tests, to make sure that wrong solutions are not accepted.

It's hardly possible to make tests able to catch all the kinds of minor possible mistakes.

In this case that's not very difficult since I propose the extra test in my original comment. It's a matter of copy/paste and you have one less bug. ;)

It they are random, you can never guarantee all edge cases are covered. You can say we want 99.9% chanche this edge case occurs. Then you can calculate how many random tests you need to achieve that. It will never be 100%. Or you can simply add some fixed tests to make sure it's covered. Why would kata's have fixed tests otherwise?

I'm rather new to codewars, but I suppose the author can update the kata if they approve?

The random tests do occasionally generate such values. That's why you can submit a failing algorithm, because of the "occasionally". That's why Im suggesting adding them to fixed tests to make sure people have to submit a correct algo.

It's much nastier than it looks.

not best practice or clever at all.

That was the issue. It's fixed. I juiced up the number on the tests to take about 6s. I suppose that's good enough to keep O(n^2) algo's from passing.

Thanks again for your help.

oh, thanks for spotting that. I will fix it.

Left a Rust translation. Please review. I had to drastically reduce the huge and big tests to make it not time out...

https://www.codewars.com/kumite/61df59fd856e34000f6fa384?sel=61df59fd856e34000f6fa384

ps: perf issue is fixed thanks to monadius.

This is a great kata! thanks. I'm a bit disgusted to have struggled for 16 hours on this to then find other people solve it in 2 lines of code...

I don't know about python, but in Rust it's good practice to write tests like:

assert_eq!( some_fun(input), expect, "input: {:?}, expect: {}", input, expect );

If the test fails it will print something like:

thread 'tests::basic_tests' panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `6`: input: [12, 30, 21], expect: 6', src/lib.rs:194:13

By printing the expect value as well you even eliminate confusion about whether left or right was the expect.