The random tests are making problems some times it expects 18 and the actual result is 9 (I think this is appropriate) and some times it expects 9 in case I change the "magic number" to 18. My solution passed on random generated value but please fix the tests. Thank you.
explicit edge cases for 11,22,33 are missing from random tests, unless randomized by (bad) luck. My solution does not even account for master numbers 22 and 33, and it's highly probable it will pass.
explicit edge cases 22,33 are missing from fixed tests, only 11 is covered by "Jesus"
Are numerology values like 15 or 21 correct, or should they be reduced further to 6 or 3? I'm not an expert on numerology, but implementation of tests do only single round of reduction, which for veeeery long words would end up with values not reduced to 1-9. Whereas the first online numerology calculator I tried, does full reduction until single digit is reached. However, random tests go only with words of 16 letters, so such case won't be encountered - which should be either changed, or mentioned in input specs.
Why return the square root of the digit sum of the string as a string instead of just returning it as-is (i.e. as a double)? It adds an extra unnecessary step to the process and is a prime example of an anti-pattern (i.e. a practice discouraged in production environments) because the resulting value cannot be directly used in calculations (at least not before parsing the double from the string returned).
Java:
camelCase, notPascalCaseRefer here on how to enable backward compatability to not invalidate all solutions
Trivial map/filter/reduce is not a novel kata idea.
The random tests are making problems some times it expects 18 and the actual result is 9 (I think this is appropriate) and some times it expects 9 in case I change the "magic number" to 18. My solution passed on random generated value but please fix the tests. Thank you.
Why return the square root of the digit sum of the string as a string instead of just returning it as-is (i.e. as a double)? It adds an extra unnecessary step to the process and is a prime example of an anti-pattern (i.e. a practice discouraged in production environments) because the resulting value cannot be directly used in calculations (at least not before parsing the double from the string returned).