For Java, in your testcases, you may want to use assertArrayEquals instead of assertEquals

python new test framework

Java fork, please review:

• move to JUnit 5
• change the imports
• annotate tests with @DisplayName and @Order
• remove a System.out.println leftover

Python: Random tests are vulnerable to input modification

python new test framework is required. updated in this fork

Inconsistent position input format (in typescript), i.e. most tests have [x, y] format, last one has [y, x]. I'm not going to implement anything to work around this discrepancy.

To find out if 3rd parameter (the upper limit) is inclusive or not, check the tests, it differs in each translation

this is not OK, translations should enforce the same specifications. It seems that Ruby and Shell are inclusive while Java, JavaScript and Python are exclusive. Shell is the original language

Print all numbers

the kata does not involve printing anything to the console. this will mislead beginners. This is probably due to the fact that Shell is the original language; there should be specific instructions for Shell and general instructions for the other languages

JS fork

• improved and hopefully clearer description
• better error messages
• mocha + chai

Code blocks in the Example section are broken. It's impossible to see the expected values.

The description does not specify whether the position input is in format [y,x] or [x,y]. This should be specified, and sample and fixed tests should be added which use initial positions that are not x = y (ie not [0,0] or [1,1], etc).

Description should be updated...

the initial position of the selection cursor (top-left is (0,0)) &
For this easy version the fighters grid layout and the initial position will always be the same in all tests, only the list of moves change.

This says to me that for this Kata, the position input for the cursor will always be top-left, 0,0. This is now (or perhaps always was) not the case and random tests do use random starting positions. My own fault for not logging input sooner, but I spent way to long before realising that the position I was treating as co-ordinates of x,y (x being horizontal and y being vertical) where not provided as expected for random inputs.

Having logged the input and completed the Kata, I now understand how the input line may have been intended to be understood. I'm sure I can't be the only one to have encountered this hurdle. I could take it or leave RE the input line, because if the the second quoted description line (that is obviously straight up false) wasn't there, I may well have read/understood that input line differently.

[JavaScript] Since the list of game characters and the initial position are held constant anyway, the user solution should simply accept the list of moves as the sole argument as the other two arguments are redundant and therefore an anti-pattern.

Tests with random position have to be added in all languages.

Already done for: JS / TS / python

Note: ./src/test/java/SolutionTest.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

since you're comparing arrays, use assertArrayEquals(), not assertEquals()