Kata

Thank you.

tray = [] is fine, and I think tray = [[]] would be fine as well, even if both are more mathematically possible than real life feasible ( or you must just want a break from crossing out banned words - why else would you be running to the shop for no coffees? :P ).

You may want to check the reference solution for its handling of [] and [[]] ( and friends ). If I allow the random tests to generate trays with dimensions of 0, it starts giving wrong answers.

This is hypothetical of course; those cases are not generated. But the reference solution does not seem to be universally correct.

Oh, I just realised what you meant with random tests. I think it's because my random test settings don't account for when the settings' swap counts exceed the number of possible rows * columns, it's safe with my own settings, but will produce errors if swap counts get too close or exceed the tray size. I'll adjust the random tests for better flexibility later.

Oh, apparently you have no reference solution. Yeah, then I see how generating an input for a certain expected number of swaps can go awry when they can't physically fit in the input.

I don't know how you make sure some rotation of the generated input doesn't have a better solution than the generated input, and I'm not reading all that code to find out. That would worry me though.

I did have the same concern, I just keep the swap counts low enough that it's impossible to have other transformations get a lower swap count than the target orientation for the large random tests. As for the basic random tests, it's possible to hit a bad test but the probability is astronomically low (the rng needs to get the highest swap count, lowest row/column counts, and swap in direct order towards a specific rotation). I have run my solution against 1 billion of basic tests and it doesn't get any bad swaps. I don't want to use my own solution in the tests to check if the swap count is in fact a minimum because that kind of defeats the purpose, so I didn't put any extra checks there, and I don't know any better way so far.

I'm open to any suggestion on a better random test though!

As long as the swap count is lower than half of the coffee count, the random generator should always generate valid data. ( When testing with 15 swaps against 5x5 coffees, it did generate bad cases. ) There is no warning for this at the call site, only at the called site, so maybe an internal assert at the called site ( with a suitably apologetic failure message ) would be a good idea. At some point in the future, a maintainer might innocently change values at the call site that break random generation. ( Future maintainer might be you, not remembering what exactly you did 200 beers ago. )

Using a reference solution only defeats the purpose when testing against the same solution. Solvers will probably not come up with your solution. :P Even if you can't use different example and reference solutions ( sometimes you can compose two completely different solutions, sometimes doing one is hard enough ), it adds another layer to testing, one that has less assumptions builtin than a biased random generator. I always like to have ( additional! ) testing against a reference solution, with fully randomly generated inputs, even if I can have test inputs generated from expected results. Some bugs may never be exposed with constrained test inputs. You never know which edge cases solvers are going to find that may not be caught by test cases constructed from expected results. With current test cases, my solution can immediately stop evaluating a certain rotation when it finds more swaps than half the input size. ( It'd be a valid optimisation even! ) As specified, that would of course be wildly inadequate. But you'll never catch me doing that with current random testing, and I can hardcode those two fixed tests that catch it.