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!

Set is a native class. You should not redefine it.

User-defined classes ( ie, Constructor functions ) should, by convention, have names starting with a capital letter.

Expecting "falsy" for null, undefined and NaN but not false, 0 or "" feels inconsistent. Easiest fix for that is possibly a different name, though I have trouble coming up with one that would naturally not include any of the others. Maybe you should just go with JS itself and expect "null" ( not the historically correct bug that is "object" ! ), "undefined" and "number".

Good catch. Fixed.

Some typos:

sting -> string
and array -> an array
and object -> an object

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.

Arrays are not tested.

No random tests.

Either the tests are lacking or that was added after the translation was made and it wasn't added to the tests.

surprising that this works, i thougt it cal also be written as "three fifty" as per the description?

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.