Apart from the case in which a ban phrase is a subset of another longer ban phrase, there should also be an explanation about the case in which a ban phrase isn't a subset of another ban phrase, yet share common words.

For example, what should be the answer for below situation?

banPhrases = ["as long", "long as"]
article = "as long as"

The former is any character. The latter is any character that isn't EOL.

What is this code for? Please flag any potential solutions as spoiler content when you talk about them in discourse.

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.

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!

Thank you, changed now!

Since we're testing integer values, assert.equal should be replaced with assert.strictEqual (the former uses ==, which enables certain hacks).

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.

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.

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.

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 ).

Thank you, I've removed the invalid null, undefined, and [[]] inputs for tray now. I've kept a tray=[] deliverList=[] check since that represents an empty tray and deliverList by default. Other than the test you've encountered in the beginning, the matching of coffee orders and coffee orderings are guaranteed in both fixed tests and random tests.