I was doing the same thing and it wasn't working for me.
I forgot to import @RepeatedTest.

I am learning about translations, markdown, and other things. I really appreciate your feedback and your help in this translation.
Thanks.

Rather than @Test use @RepeatedTest(x) where x is the number of times the test should be repeated.
E.g. @RepeatedTest(100) to run the test 100 times.

(Made a fork with that implemented)

I don´t know how to realize the @RepeatedTest without a for loop.
Could you help me to do that?

My mistake. I used the Python description as a reference. It's already corrected. Thanks for pointing that out.

No, they are inside the class so you can use them all you want. Being private just means they can't be accessed by instantiated objects.

all occurrences

will this solution delete all the repetitions of the letters in text (e.g. "a" found 2,3.. n times) or delete only one occurence?

Can someone please explain why this solution is most voted as Best Practices? it's a concise one-liner but I thought loop-based solution might be more appropriate.

SolutionTest.contamination(String, char) should be private.

It would be preferable if SolutionTest.randomCharacters() returned a single String.
In the same vein random tests could use @RepeatedTest as opposed to a for loop.

Very cool solution, I need to get better at ternary statements and this helps thank you.

That which you mention is not a Java bug.

Comparisons between primitive types do not produce the errors you mentioned, and the "equals" method

of Integer class compares whether they are the same object by comparing if are of the same class and their values.

Integer equals:

public boolean equals(Object obj) {
    if (obj instanceof Integer) {
        return value == ((Integer)obj).intValue();
    }
    return false;
}

I've solved that problem. There was a precision issue in test case.

Please use spoiler flag next time.

how does this work exactly??

Hi.

I made a change to ensure that an error of 1E-10 or less is considered valid.
There was a small chance that it would not pass in the tests or your solution.

return Math.abs(width - height) < 1E-10 ? "perfect" : width > height ? "fat" : "thin";

instead of:

return width < height ? "thin" : width > height ? "fat" : "perfect";

I made these small changes because there were times when, even though the square roots were in the same direction in both cases, the test didn't match those roots within the margin of error and gave a slightly different result. This change fixes that, and in 100000 tests performed, there is consistency.

Best regards.