Thank you, fixed!

If it's called with new, this is entirely different and the usual implicit return undefined is replaced with an implicit return this. A different prototype will be attached as well.

That is why my lithmus test is "is it called withnew?".

If it's not called with new ( and in this kata, it isn't ), it is confusing to name it with PascalCase.

In JS using assert.isTrue instead of assert.equal is unacceptable as it gives no feedback on what's the expected and actual values.

JavaScript by convention uses camelCase for non-Constructor function names. Please follow this convention.

Isn't it considered a constructor for naming purposes? Just a different style of a constructor...

Got it, thank you for your directions.

You can hide testcase names, but failure messages should indicate something useful for debugging. That goes for any estimated rank, really; making it impossible to debug is not a good way to increase difficulty of a kata ( it is a good way to frustrate and lose your solvers :).

Regarding your actual question: it doesn't matter too much. Your estimate doesn't affect solver rankings or eventual approved rank.

But if this is intended as an 8 kyu kata, take the user by the hand a little ( especially when tests fail ), and don't do confusing things.

Thank you for your recommendations. Which level is appropriate to set if I want to hide testcases names?

From an 8 kyu kata ( your estimate, apparently ) I would expect better test headers and failure messages, and no stderr complaints about Buffer.

JavaScript by convention uses camelCase for non-Constructor function names. Please follow this convention.

Please provide sample tests.

Thank you, fixed.

Description is updated.

I've added reshuffling for the test set.
I don't see any point in adding random primitive values, as long as this task is almost about handling corner cases.

This is a good point, and that was mistake in my solution.
I've added tests fo NaN, Infinity, +0/-0/0 test cases and warning in problem description.

The reference solution expects equals( NaN, NaN ) => true. There are very good reasons why NaN should not be equal to NaN.

In general, you are expecting solvers to redefine equality to something different than any of the normal JavaScript notions of equality. There are very good reasons for JavaScript's notions of equality.

If you think it is a good idea to make a kata out of another notion of equality,

• think again
• specify exactly what you want
• explain why you think it is a good idea to define another notion of equality
• and finally, just don't

Making a JavaScript kata out of redefining JavaScript is a contradictio in terminis if I ever saw one.

Please specify what equality means.