Just added them to Ruby and several other languages, now all of them have the mentioned edge cases

A sample test has been added.

So compact!

Apologies. Like any other "unresolvable" bug, it turned out to be a typo. I was unknowingly recalculating my return value using bugged out code, and did not notice. The disambiguity finally helped me narrow down the location of the bug.

So please consider adding that one test line to the code. It's pathetic, I know, but it would have saved me over an hour of my time, by being certain the problem was in the code, not in my logic.

A reflection is its own inverse. Performing the reflection twice returns every point to its original position.

It is unclear what the inverse of a reflection is.

With rotation, reverse can be defined as an operation to undo the operation, or an operation which of the opposite direction.

I am however having problems in inversions of a reflection. If it is to bring back the operation to origin, then its the inverse of itself (which is mathematicaly correct but feels "too easy"); If it is the lexicon opposite, then it would be a flip of 90 degrees (eg. vertical -> horizontal). Neither currently works in my code, and until the ambiguity is cleaned up, it will be hard to bugfix.

Part of the problem is that there are no inversions of a reflection in the visible tests. One additional test will fix this issue.

And to answer to your last question: No, there are no bonus points here. The tests don't analyze your code; they just control your answer (I think this would just be practically impossible).

This kata is old, has been solved a huge amount of times, and changing its design in the sense of your suggestion would invalidate most of the submitted solutions, and actually would make it a completely different kata. This is not going to happen. Howerver, there exists a good amount of more challenging katas relative to arithmetics and divisibility for those who are interested in it..

The test cases dicourage efficient code. The original problem asked us to calculate for the number 1000, while the highest test case is 200. I think timeouts should be implemented and more extreme tests given. For example, my solution can get a result of 1890045000 from an input of 90000, in almost the same time as a low number. Going any higher gives the risk of breaking the ceiling of a signed Int32 (which can be be fixed by changing to an unsigned int32, or even an Uint64 hahaha).

Changing the test cases to a higher value will encourage mathematical thinking and efficient coding habits. This would also have to be reflected in the explanatation for the problem. I am new to codewars, so I don't know if there is some sort of "bonus points" system, which would fit this perfectly.

This is a hybrid solution, where the sum up to the nearest multiple of 15 is calculated, and the rest are iterated (maximum 11 iterations!).
I could have commented the code better.

Good peformance, and in addition very readable.