I mean, when I was creating the test cases, I wanted to cover every possible cases to generate undefined value, either by passing an explicit undefined, or passing some expressions which will generate undefined implicitly. (or at least cover some of these cases :))
It can be that since every expression will generate the same undefined value, creating 4 tests were needless...

Maybe those tests are useless, but gives higher coverage, and they doesn't affect the possible solutions anyways. But good points there, thanks. I will review them.

True :(
Long day + 11PM = upper

Modified description. Being more precise on method description would mean a so big hint, that the apprentice wouldn't take any time searching for possible solutions, since everything would already be in the desc.

I modified the details, i dropped isObject, but also mentioned it :) Thanks for the advices. Also if you have some suggestions for the tests/etc please provide ;)

Hmm, you have some point. I really don't want to let this topic go, since this really bothers me, and my mind, but if it is misleading to new learners, then would be happy to delete this kata, than making bad intentions in newcomers. If some more people will vote for a drop, i will drop this.

Question: Are you satisfied with the conventional ways for type checking?

Maybe it just me who are not satisfied enough with the ways we validate input arguments now :) I know, i know, TypeScript, Dart, other transpilers... :)

Partly agree. I agree that it is JavaScript which is a dynamic language, it was not designed to work with types. But, this site, and this kata is not intended to be a reference for type checking, it only covers an uncommon case/task in JavaScript. Maybe checking if new String(smtg) is Object or String just doesn't make sense, but we can do this, and i think its worth to make a kata around this issue. There are plenty more katas here what only reflects to one of JS's uncommon features and the warriors can profit from them, not because they are advised to use it in prod, but they will see these cases once in a while. Thats my opinion :)

Btw i did this kata TDD style, i first wrote some ~50 test cases, then made the default "solution".

Hi, thanks for the suggestions, i updated the description, i hope its more clear now. Please provide more feedback if you have time ;)

After all, i'm still not convinced why isObject should return true for []. Could you please be more specific? Maybe my description was bad to use the word type. I think a function isArray should check if the argument is an array, isObject should check if the argument is a JavaScript object, not OOP object. I don't know if you are familiar with jQuery, but according to the reported issue, $.isEmptyObject should return true for [] since [] is an object, and empty. But its not the case. What do you suggest? Remove isObject method from the kata, or the tests should pass on isObject with an array as argument? That wouldn't make sense imho :(

Returning true for isObject([]) would be misleading, say i want to check if var myObj = {prop: 2} is object, then perform hasOwnProperty on it would lead to unexpected errors. Otherwise, I understand your concept, maybe the name isObject is misleading, isPlainObject would be better.

I suggest to extend the test cases where an elem in the input array is e.g. new Number(2).

I assume this solution is incomplete, please see my kumite for failed test cases.