approved, thanks for your efforts (note that in the future, if you're going to add messaged to all assertions, you can write a wrapper function to handle that: it gets rid of hardcoding and makes the lines shorter)

done ✅

• Added Messages to every assertEquals
• Added @DisplayName to both functions in Test Cases

if a translation has poor coverage you are allowed to do better in your own translation ;-)

it's especially relevant here because Python's integers are arbitrary-precision, while in Java the output is an int, which means potential overflow errors.

but fine, let's do it your way

one last thing: please use the optional JUnit message parameter to display the input to the user in the random tests. it's easy to do and it makes the user experience a lot better on Codewars

And the help section for a translation kumite says:

You should try to keep the test cases as similar as possible to the
test cases defined for the other, pre-existing, languages that the kata supports.

Fixed the second point ✅

First point:

My test cases are based off of the Python translation, which generates numbers from 1 to 100:

 for _ in range(100):
        
        a = randint(1, 100)

Second point:

I'm so used to doing Groovy translations, which are restrained by JDK 11, that I forgot that I sometimes forget that I can use JDK 17 features when using Java. And yes, I have created a GitHub Issue about an updated version

• why is the random tests' range so small ? the input can go from 0 to 1023 (which should be added as a fixed test: assertEquals(1_111_111_111, Kata.toBinary(1023));
• nextInt() has an overload with 2 parameters, so you can write n = random.nextInt(0, 1024);

fixed

• remove the toBinary/to_binary, "write a function" is enough; the solver will know the function name from the initial code.

• perhaps adding "as an integer" after "binary format" would make the task clearer ? right now, someone could interpret it as returning a string of zeroes and ones

Done ✅

the description is extremely bloated for such a simple task. can you use the opportunity to make it language-agnostic ? remove the mentions of functions' names, and erase all of the code blocks except one.

Rejected due to unmergability (description), lack of random tests, and scala 2.x.

Any particular reason why traversal on Long is used instead of Int which requires only accumulator to be Long type? Is it to force sum to operate on Long?

Ok, i'll add it soon)

Looks better, thanks.
I'd suggest including a set of random tests as well.