And is correct that way because inputs "... are always lowercase strings, and that each has at least two letters.". If that was not the case and arbitrary inputs would be allowed we'd also need checks for null and lengths in order to avoid NullPointerException and IndexOutOfBoundsException or alike.

That test would need to be able to distinguish narcissistic from non-narcissistic numbers somehow, so you would either still be able to extract all narcissistic numbers or would have some other kind of solution in the tests which could then be copied from there.

Regarding testing non-narcissistic numbers both randomized and non-randomized: It has basically been "copied" that way from the PHP transaltion.

Honestly I don't remember. Maybe because it's the lowest positive number that is non narcissistic, but today I wouldn't say that this alone makes it qualify as an edge case.

That's a good idea. I have never really understood how translations on CW should be done (I believe mine is based on PHP) and how to deal with issues that possibly affect multiple translations or even may have multiplied from translation to translation. So if anyone else could do something about it that would really be awesome.

As some issues deal with the tests: I don't see any guidelines at CW how tests should be written. Having only few sample test inputs may make it more challenging in the long end. That's a matter of taste and it's pointless to have a discussion about it when there's no general definition of the scope that these sample tests should have.

Personally I think that description, solution and tests are fine. The same is for my addition of a hint regarding the character ^ being an operator in Java, and thus should not be understood like that in the calculation. If that makes other people use words like "wtf" then these should go ahead and strive for their understanding of perfection in their own fork. Time is too valuable to be wasted for discussions about matters of taste here on Codewars, so I feel quite confirmed that it isn't necessarily a bad thing to come back here only once in a while. =)

Never recognized that before, thanks for letting us know! :-)

Using chained ternary operators in a uniform way like here isn't bad practice either. It's very easy to grasp that the value literals are increasing upper bounds. Write the same as a chained if-else-if-construct has the advantage to be able to set breakpoints when debugging but also the disadvantage of a worse signal to noise ratio due to many ifs, elses and returns. I think the main reason people still prefer that even in simple cases like this one is that they're used to it. =)

This solution does not honour "If there are less than n occurrences of the substring, return -1". It will fail e.g. for FindOccurrence.findNthOccurrence("a", "aaa", 5) where it returns 0 instead of -1.

Doen't work properly with e.g. FindOccurrence.findNthOccurrence("a", "aaaaa", 5) where it returns 3 instead of 4. :-)

This solution does not honour "If there are less than n occurrences of the substring, return -1". It will fail e.g. for FindOccurrence.findNthOccurrence("a", "aaa", 5) where it returns 0 instead of -1.