for me it fails in Java.
if I change this: ->
assertEquals("Halifax, Montreal, Toronto, Chicago, Winnipeg, Seattle",
routes.findRoutes(new String[][]{{"Chicago", "Winnipeg"}, {"Halifax", "Montreal"}, {"Montreal", "Toronto"}, {"Toronto", "Chicago"}, {"Winnipeg", "Seattle"}}));

to this: -> assertEquals(Chicago, Winnipeg, Seattle",
routes.findRoutes(new String[][]{{"Chicago", "Winnipeg"}, {"Halifax", "Montreal"}, {"Montreal", "Toronto"}, {"Toronto", "Chicago"}, {"Winnipeg", "Seattle"}}));
it works fine but still it is changed back when pressing submit.

I strongly agree. Also with the return type being int I missed a clear expectation of how overflow should be handled. The expectation is only defined implicitly by the (failing) tests, which is not the nicest way to define how to handle these cases.

The Submit tests only test for the element at index 1 when the input array is null - it should also check that the element at index 0 is 0 in that case.

@Ndumiso,

FYI here is a guide on writing random tests. It's in JavaScript and not Java but the overall concepts should be applicable anyway.

How do you see the input ?

raise to the power, thanks

As far as the current test goes I can return new int[] {1, 1331, 2, 3, 4, -1, 0} and the test will still consider my result correct.

Please use assertArrayEquals in place of assertEquals so you can test equality in one, single test that will ensure the content is always equal.

Is the null test necessary? What does it even achieve?

By how the kata is defined the number will be out of the range of an int (and even a long) very quickly. The return type should be BigInteger.

and square each sum by it's corresponding number of occurrences

This is the wrong terminology. Squaring a sum is always raising the number to a power of 2, but in here we're required to raise the number to the power of the occurrences instead.

Your tests organization makes no sense. Why is there a non-null test in the testNullability?

except if you print them with Arrays, so that's fine by me... ;p

[1 3 7]

That's not how arrays in Java look like...