I would advise against Object.freeze(Math) since that doesnt prevent just deleteing Math and redefining a new Math object.

Codewars test framework already has a method for determining if floating point numbers are within a margin, use test.assert_approx_equals(actual, expected, margin=margin) instead of measuring the delta yourself.

Random is not seeded with srand(time(NULL)), so the random tests generate the same output each time.

The BigInt primitive is in stage 3/4 of the ECMAScript specification, and not all browsers/engines support it. The latest version of node to support it is 10.4.0 and since this kata doesn't support 10.4.0, the BigInt primitive does not apply.

More accurately, it seems replaceSpacess is the name of the function that the test code uses to generate the expected solution, and that it was simply not included in the test cases. Thus, random cases can be bypassed by just making sure replaceSpaces and replaceSpacess return the same thing.

If I am understanding the description properly, the test cases seem to be incorrect. If percentile = participants_you_are_better_against / all_participants * 100, then for each percentile, (percentile / 100) * min_participants should be an integer, as people cannot be fractional. However, both the fixed and random cases don't reflect this.

In the fixed cases,

50000 should equal 166667 given [93.234, 49.89]
50000 * .93234 == 46617
50000 * .4989 == 24945

50000 works and is smaller than 166667. In addition, 166667 does not work

166667 * .93234 == 155390.31078
166667 * .4989 == 83150.1663

166666.6 repeating works, but that would imply that non-integer participant counts are allowed.

Some examples in the random cases:

Tested on list [34.0, 87.694, 10.7]: 50000 should equal 1000.0
1000 * .87694 == 876.94
50000 * .87694 == 43847

Tested on list [39.062]: 50000 should equal 500000.0
500000 * .39062 == 195310
50000 * .39062 == 19531

Tested on list [21.0, 99.0, 22.0, 25.0]: 100 should equal 4.0

Either the test cases are incorrect, or the description is incorrect

Test #4's description is a bit off. Numbers 1-3 say lowerCaseLetters should be {expected}, but #4 says lowerCaseLetters should be {input}. If you would liked to show the input in the test description, maybe have something like lowerCaseLetters({input}) should be {expected} Also, #4 is not very good as a random test. The input is a template filled with numbers and the output is fixed, which allows for hardcoding. True random tests would be the best, but if you must use template based tests, then thrown in some spaces or capitals rather than just having the alphabet with two digits between each letter.

Random tests could be implemented; although, it will not be an easy task to do.

One-word search queries would be pretty easy. Generate a random word string for the text, and randomly pick or not pick one word from the string. However, multi-word random tests would be harder to accomplish.

One way could be to use a fixed boolean search pattern, such as '({} AND {}) OR {}', and fill it with randomly generated words. You could then check using your own algorithm, and compare to the user's.

There are probably multiple other better ways for implementing random tests. Anyone else have any ideas?