check that the output is made of the expected type of data

For some reason all fixed inputs are tested using the reference solution despite clearly having only 1 possible result each :\

Added sample tests to fixed tests, and rewrote the "out of bounds" assertion.

as cocky as usual! x)

You don't get the point. Look at the way doc's doing this kind of tests in his hard katas: the first thing he does is to check that the output is made of the expected type of data. This way, the user get a useful assertion if he does something (very) wrong instead of a nasty total crash. So that's actually a valid issue, even if you don't like it. ;) (see this as something that can improve the experience of the user ;p )

What are you even talking about (both of you)? There's an example in the description telling that the output should be formatted as ["down", "down", "right", "right", "up", "up"].

it should be simple enough to explicitly cast the number to a string

Except I can't read your mind, and I can't tell how you managed to express cardinal directions through integers.

Anyway, not an issue.

na, what I mean is that your solution should return something like ["down", "down", "right", "right", "up", "up"] but it seems that your code puts numbers in there. So there shouldn't be anything to cast to string, actually. But effectively, the test function should warn the user about that, rather than just fail when a wrong data is found in the returned list. ;)

EDIT: well, a forced cast to string would be a soltuion too, yes... x) Tho, the other way would be better.

seems you're returning a list with numbers instead of strings, so that comes from your side. But the tests should effectively be made bulletproof, about that.