Yes, there was low entropy as far as the expectedResult was concerned (only 3 random strings / 825 cases). The rest were given by the cases for the strand length (11) and the index at which the match starts (25 cases). 3 * 11 * 25 = 825. It was inefficient.

I've updated the JS tests and was more explicit about the variation in the location of the match. Also, the expectedResult is now different for each case of the two describes, each with 11 * 25 cases.
Also updated the Java tests to match.

Might need to improve test for the reversal of arg order, as it relies on the low probability of multiple solutions being randomly generated.

Later edit: Wrote a solver inside tests, to specifically filter for cases with unique solutions for the test that required it and ran that over random sequences. Used static array of oracle unique solutions instead of a random method until something better to determine uniqueness of solutions comes up, as the solver should not be part of the test code.

I'm sorry if I came off as petty. I was taking a philosophical standpoint. This wasn't about performance, rather about responsibility. About the habits that become ingrained in the developer in different contexts. Should you be careful with the data you are given or not? In some languages where data is immutable, this doesn't matter. In others there is a clear rule that can be enforced (this was the Rust example). Yet in others, you should enforce these rules yourself.

I understand what you are saying, because people will toy around with various methods and will sometimes mutate the input. Sometimes they will find a solution by doing that, and then wonder why tests break. So it is important, as a platform, to be robust against that.

I am merely wondering whether or not this puts us in the mindset of solving local, isolated problems and we stop looking at the broader picture.

I don't mind changing the tests or doing this in one way or another. It is software after all. 🙂
I just felt the need to express something I felt strongly about. Maybe my worries don't have their place here.

Again, I appreciate the feedback.

Very well, I'll change the tests assuming that the args are disposable. But the way I see it, if the goal is to write robust code, it's also not a good thing to give people free reign to mutate the input in an operation that finds things (i.e. something that can always be done as a "read"). I could just as easily make this requirement explicit and add a test for it, rather than always passing a copy of the array to the user.

It is things like these that motivated the borrow-checker in Rust, where the ownership is made clear at compile-time. In short, we are going to do it the Rust-way, where the args don't have a lifecycle outside the function scope and the "easy" fix is to always pass a copy.

Yes, this is generally a question of the contract of the method. I did not expect the user to modify the input in-place.
What are the expectations? Should I mention this in the requirements of the kata? Should I switch to a String signature in Java for immutability?

Thanks for the feedback. I've used a constant in Java version and improved the tests in both languages a bit.

C++ tests using random a,b bounds do not allow for inclusive interval [a, b].
For example, a=1095 and b=2427 expected {1306, 1676} but 2427 is also the sum of "digit powers" (2 + 16 + 8 + 2401), so more correct is {1306, 1676, 2427}

On subsequent re-runs my code passed.

Yup. It's my fault for having skimmed through the text. Can you believe that I was blind to that "total" for the first 2-3 reads?
While this succinct form of the requirements might be in line with higher-ranked Katas, such a low-ranked Kata will be hit more often by new users. I believe they could benefit from a more in-depth explanation or an example, as their main focus will be on the specifics of the new language (SQL) they are trying to learn.

Ah, the problem was that the Kata did not explain what 'area' represented.

6 is the sum of the area of all the faces of the rectangular box.
I took it to mean the area of the base.

Later edit: My feeling of wrongness stemmed from the intuitive idea that (asymptotically) the 'area' < 'volume' (when using same units)

SQL tests expect wrong values for area.
For example, for a row with {width:1, height:1, depth:1} the expected values are {area: 6, volume: 1}