Good point about Set. I've prefixed the test constructor so there's no name conflict.

I'll also consider changing 'falsy' to null and undefined. Thanks for the feedback!

Good catch. Fixed.

I have added functions into the mix. My apologies if your solution became invalidated.

I won't add any additional requirements to the kata from now on. (I'll only fix issues, if any come up)

I didn't think random tests would add much (if any) value to this kata so I didn't implement them initially, but I've added them in now that I see that a function with an array of strings passes the normal tests. The new test cases now test a randomized amount of assorted values from an array for each 'type', which should prevent any 'cheesing' like having the function return a set list of expected types.

I did forget the array test. Thanks, added it in.

String(Number(octet)) === octet

This is perfect. Wish I'd thought of it.

There was an issue with the second and third batch of random tests always displaying the initial board as entirely filled with just 2's. This has been resolved and the actual inital board state is now displayed. Additionally, the description has been updated to state that the updateBoard function must return your answer- simply modifying the input value is not enough.

Thanks for the callout! This restriction was never intended. To remedy this, I've modified the test suite to copy all inputs to the user solution using Array.from() so that the user solution does not have to be a pure function. (If it isn't, it will modify a copied value, which won't harm anything, but also won't solely fulfill the test requirements)

However, modifying the test suite to take the modified input value into account in addition to the return value would be a lot of effort on my part, so I've updated the description to specifically state that the answer must be returned from the updateBoard function.

After fixing another few issues... (sorry for the wait!) I feel confident that this kata is finally in a good state. If you submitted recently and got an arcane error, please resubmit your code if you still have it.

I've made the following changes:

• Fixed a bug with the test's solver. I've manually verified countless randomly generated solutions so my certainty is pretty high this is working as expected now
• Tuned up the reporting in the test suite so that reports from random tests now read side-to-side to make it much easier to see the test outcome and why the test failed
• Increased the rigor of the random tests dramatically. Instead of generating 1 random board for each direction, 3 times (a total of 12 assertions) the suite now generates three sets of boards (5, then 20, and finally 100). The user's solution is then validated against the test's solution for every direction (this is HUNDREDS of assertions).

This is likely due to an error in the tests. I am pretty certain I've fixed it now so if your solution works, you shouldn't see this error again.

Also, I've beefed up the test suite to make its checks more extensive and its reports more readable. Thanks for your comment! Please resubmit!

Ah, there was a copy + paste error in the test! No rotate method should be allowed. Thanks for pointing that out!

I've fixed the issue, and also beefed up the test suite! Please try resubmitting :)

This is super interesting. I didn't even realize that input modification was possible here, but I was able to trick the test with the initial solution. Each test now receives a copy of the random board for that portion of the test fixture using:
Array.from(originalBoard)

instead of a reference to the source board (which the test asserts against, allowing the trick). This should prevent further muddling with the random tests.

I also modified the test to read from the user's TFE object instead of the fixture's, so now you can modify the direction values to your heart's content :)

Thanks a lot for your feedback!

After much reworking, the random tests should now be working better. Thanks for the feedback and sorry for the wait!

This is true! There was indeed still an issue. I wrote some additional tests to prove this case and re-worked the solution to meet these tests:

The previous tests confirmed that the row

4|#|2|2

when shifted right, would combine correctly to

#|#|4|4

But the solution still combined the row

2|2|#|4

incorrectly into

#|#|#|8

This has been fixed. Please re-try your solution to confirm, and thanks for the feedback!