Would you like to tell how this code works?=?

i can do it. Let me try it.

That's briliant but from my point of view this loooks easier:
String numeroMaximo = Arrays.stream(Long.toString(number).split(""))
.sorted((a, b) -> b.compareTo(a))
.collect(Collectors.joining());

Oh man! I couldn't think it could have been done so clever like this :) Especially it avoids floating point computation and the hurdle of conversion floating point value to integer.

The tests look fine now, I think

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.

There's something wrong with the JS random tests, they're testing a few randomly generated tests for hundreds of times, so effectiviely there are only a few random tests.

This wasn't about performance, rather about responsibility. About the habits that become ingrained in the developer in different contexts.

Well, in this case we're writing test code for a coding challenge that evaluates user's code, so the tests should be robust enough for common things. Test code should be subjected to at least the same standard as user code. If user can easily break the tests and cause false positive/negative results just by mutating the input (which is not exactly something rare, or even intentional), we'd say that the test code is poorly written, not that user code is doing something malicious.

And in 99% of the cases, whether user mutates the input or not is irrelevant to the task at hand, so there are also no particular reasons to restrict users doing that. It's better to just let the tests gracefully handle it, rather than escalating the situation telling the user "why are you mutating the input, you're WRONG, re-write your code". That'd be like a inflexible, draconian commit hook rather than actual teaching.

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.

I don't see how any of this has anything to do with Rust.

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.

This is much more effort than just passing a copy. Not to mention, if you want to test the input isn't mutated, you'll need a separate copy to hold that information, so it doesn't save anything over just passing a copy. At best it's just a very petty practice that doesn't bring in anything useful.

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.

I did not expect the user to modify the input in-place.

Test code should be as robust as the user code; it's not good (and generally unacceptable) if modifying the input can easily break the tests.

This should be mitigated if you pass a copy of the array to the user function. Other languages where strings are actually an array of mutable characters (e.g C and Ruby) will need this as well.

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?

Now there's another issue in Java version: if user mutates the input the tests will erronously fail.

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