Fixed in this fork

Added some time ago

No longer an issue.

If there are test cases which always expect some specific answer consistently in the same invocation, it makes test cases suspectible to counting. Users can use a global variable to count invocations of their solution, and return true, false, or None or some other predictable result for every expected n-th invocation.

This problem might not be especially relevant for some kata, the most affected kata are the ones which expect bool as an answer, but the general practice is that for random tests, the expected results (and their order) should be unpredictable This can be achieved for example by generating a list of inputs for all tests, and then shuffling the list.

How does having separate tests expecting None make it easy to cheat?

rejected for not enforcing the use of a regexp

this has been fixed

Descriptions are generic, it is clear what tests expect when one sees the code.

FIxed some time ago

Don't make separated tests for None, or it's easily cheatable. You should create tests expecting None inside the same series. You should also shuffle the characters rather than just concatenating twice the input. Also, with this method, inputs expecting None will be statistically twice larger than pure random inputs; both should have the same average length.

The translation also needs to be updated to the latest version.

It makes no sense to have a 4kyu kata that may be solved by just using a built-in function. Learning to use built-ins is 8/7kyu level.

Looks good. However I don't understand why numbers are generated this way (I see it is the same in JS, but not all languages do it, and there is no reason to avoid to have zeros in digits). Also, you must update to the latest version.

Please include true random tests, and not a bunch of shuffled fixed tests. Most likely the descrption has been updated since you published your translation, so it's probably more secure to publish a new fork grabbing the current description (the best solution would be to make description language agnostic to end with those endless merge conflicts).

Tests are really too tough compared with other languages (see topvoted Python solution), I'm using HashMaps as counters, my solution is similar to yours (linear) and it times out on performance tests, obviously it should not happen. Tests should reasonnably only discard the most naive solutions (nested O(n2)). Also, you must update to the latest version, and you will have a merge conflict with description so a new fork is required.

Actually each language expects its own thing here, the current description is accurate only for Haskell. The description should be generic, the details for empty output would have a better place in respective solution set ups.