• Each of these three parts is only allowed to be 20 less or 20 more or somewhere in between (in decimal). should be reworded to the difference between each three color parts of the pairing should be less than or equal to 20

• Does not mention the format of color code (whether lowercase characters are allowed)

• In 3rd requirement: [['#271285', '#232189'], ['#AA728B', '#BB7281']] is a valid ... should be [['#232189', '#271285'], ['#AA728B', '#BB7281']] in accordance with the previous rule on smaller hexadecimal number preceding bigger ones

• 4th requirement && 2nd example: can not --> cannot

• 2nd requirement: The firs color --> The first color

Uneinheitliche Syntax in deinem Mapping triggert schon bissl xD

The description states: The array of pairs must be in ascending order ... In the case of two pairs with the same first color, the 2nd color must be in ascending order.

There are some tested pairs with identical red and green parts and different blue parts. These need to be sorted ascendingly based on blue to pass the tests.

While this is easy to infer, I suggest changing the description

Works like a charm. Thanks!

• set chai.config.truncateThreshold to 0 ( see the notes in the test box in a new kumite )
• if there are any errors, the first one will be shown at the bottom. just ignore it; it's an artifact of stderr

With Node 10.x, you need some boilerplate. I just put

const {assert,config} = require("chai");
config.truncateThreshold = 0;

in Preloaded, because I don't want to see it.

Hello, I wrote some describe and it-headers but two issues occoured. I thought you might know something about them :/

• With Node v10.x long arrays in errors don't get displayed properly. It just displays expected [ array(4) ] to deeply equal [ array(4) ] so the user can't see the difference. Is there a solution except transforming everything into strings?

• With older node versions, arrays in errors are displayed better. But I noticed that below all the proper test outputs an unhandled error field is always displayed. E.g. Unhandled rejection TestError: Expected: ['#ffffff'], instead got: []. I am not shure why. I thought I handle all the errors properly.

Thanks for the fix. It should now work like the solution in your fork.

@JohanWiltink, thanks for letting me hijack your solution btw :/

@Blind4Basics, random tests are now executed after fixed tests.

@Unnamed, issue should be resolved now.

note that the random tests should be executed after the fixed tests.

And the issue with my own solution is fixed as well.

I can't recommend extending prototypes in tests. See the tests of the fork of my solution how to make it selfcontained.

I have already fixed colour0!==colour1 in the tests, but you can put this in yourself.

About colour 0 !== 1: if duplicate colours use different casing in the input, it won't be recognised. That doesn't happen with tests as they are ( everything is generated in uppercase ), but there's still ever more devil in details ..

It actually wasn't fixed, but it is now ( I think ).

Thanks for testing. I originally didn't intend to allow arrays with duplicate entries as input, so I forgot to consider that case.
It is fixed now. I also added an array with duplicate entries to example tests and static tests.