• Why would you not log the entire actual and expected values in sample tests, like in the test cases?
• Logging the actual and expected values on a single line is not user friendly for debugging

A hash is a one way encryption technique

Hashing and encryption are 2 different things, don't spread misinformation.

The description would benefit from some markup and some newlines ( esp. the Q&D part - I haven't even read the unquick part ) - it's a massive, monolithic block of text ATM. Breaking it up a little could work wonders for its readability.

Random tests sometimes generate test cases with n = 0:

works for string length 117, with new color purple and n 0

I have generated this placement for the last sample test, and I agree with the sample test code that its score is 72, which is higher than the hardcoded optimum score of 68. What's going on? Is it an invalid placement (and which rule does it break)?, or are both the sample test code and I miscalculating the score?, or is the hardcoded optimum score wrong (and should the optimum scores be hardcoded)?

 H ,eT , H ,   ,eH ,   ,   ,   ,   

 H ,eH , H ,   ,   ,eH ,   ,   ,eH 

   ,   ,   ,eH ,   ,   ,   ,   ,   

 H , H ,   ,   ,   ,   ,eH ,   , H 

 H , T , A ,   ,eH ,   ,   ,   ,   

   ,   ,   ,   ,   ,   ,   ,eH ,   

   ,   ,   ,   ,   ,   ,   ,   ,   

eH ,   ,   ,   ,eH ,   ,   ,   ,   

   , H , H ,eH ,   ,   ,   ,   ,eH 

   , H ,eA , H ,   ,   ,   ,   ,   

The sample tests call countNeighbors, which is not defined. While the solver must work towards that functionality in the course of solving the kata anyway, if you intend for the solver to define and implement countNeighbors themself, it would be better to say so explicitly in the instructions rather than make them look through a bunch of sample test code to figure out its signature and expected output.

The description specifies modifying the input. ( No really, read it. )

In this case, returning a value does not make sense ( though it is consistent with the JS design atrocity that is eg. native sort or reverse. taking bad design clues from a language does not make them good design though ).

The better option would be to specify returning a new value, and ensuring arguments are unharmed.

Please teach good habits.

Why are we being tested for needlessly hugh array ?

Add
chai.config.truncateThreshold = 0;

to both tests, because right now all I see is

Expected Array(n) to deep Equal Array(n)

Where n is any number

• Tests don't show actual/expected values correctly
• Random tests are unreasonable huge
• The user can modify the input
• Trivial map/filter/reduce is not a novel kata idea

There's already an exact same kata, although with a fixed instead of dynamic array length (which is really irrelevant).

This looks very familiar, though not under the "Farkle" name.

Are you sure this hasn't been done?

Some example tests would be nice :)