In addition to what laoris said JavaScript does not use the Indian Calendar natively. So if you are writing your own tests using values from the web sites calendar rather than the day JavaScript returns you will never pass the tests with an Indian calndar driven test.
The values I use in the hard-coded tests use the values JavaScript returns by default, therefor it doesn't matter which country you are doing the Kata from as JavaScript sticks to it's native clendar type and always return the same day for a date no matter where you are (unless you intentionally convert it).

The idea of the Kata is to get the person to deal with the JavaScript quirks which turn the 72 into 1972 unless you do what you have to do to pass the Kata.

Interesting solution, though I do have my reservation ''+num being called cheating when it is using build-in JavaScript behaviour and is one of the fastest solutions as well.

Not even sure how cheating is defined in this context, wouldn't it rather be that ''+num is implicit type convertion while toString() and String() are explicit type convertion?

@wasche: Have you had another look at it to see that the current century has nothing to do with the solution and re-reviewed the Kata again?

How can I see what the minor issue is that was reported on my Kata?
How do I know which comment is related to the minor issue report, are the comments marked so we know which ones they are?

Also, what if a person reports a minor issue but it turns out that issue was not an issue?

If you reported a minor issue can you please highlight what it is?
As I explained the century has nothing to do with this, so if that is the reason then there is no issue as the only years assumed are 1-99.

If you didn't report a minor issue with this Kata, how can I see who did and what for, so I may address it and fix it?

@akoptsov

Hi

I have now 7 standard fixed tests to test at least each weekday once.
I also added 10 tests which generate random dates to prevent hard-coded solutions.

The output of failing tests are also now using behaviour driven syntax "WHEN...THEN..." detailing the values passed and what the expected and actual days were.

You can see the tests in the solution section.
As you suggested I think I covered the issues with hard-coded solutions but yet still be able to give as much details to failing tests as possible.

Thanks again for the feedback.
Feel free to let me know of anything else you might notice that could improve the quality of the Tests and/or the Kata.

Ah, that's interesting, I never thought of that.
Makes sense in this case.

I can add some Math.random for day, month and year values, combine them and loop through a few tests.
Not something I would do in a real life application test but I like the idea to prevent hard-coded solutions and give a warrior as much info as possible.

I have to wait until I get home tonight to update this properly.

Thanks a lot, great feedback :)

I originally was going to add the full date into the output message that I tested against but at the same time did not want anyone just then hard-code the results into the function.

i.e: If string === 'xyz' then return 'Wednesday'

I couldn't figure out how to prevent those solutions while at the same time giving more information in the output.

That is why I opted for 2 example tests added by default so the user can use them to verify and as a template to add more user unit tests.

I guess I could add some with verbose outputs while leaving some with just the standard output.

Would that be more helpful?

While it does, it actually shouldn't as the Kata states: "Note: calendar used in the kata is Gregorian."

As the Gregorian calendar only dates back to aprx 1582 any year specified pre 1582 should be rejected by the method as invalid as the outcome is purely speculative in the context of the Gregorian calendar's existance.

That can be well seen when using 25th of December 0001 as the day given by JavaScript does not match the day given by a backdated Gregorian Calendar.
As it is pure speculation though it could not possibly have a passing unit test.

In addition the unit tests used to pass this Kat are flawed.
See the current top solution which like many other cause any date with a year less than 100 to the converted into the wrong dates, i.e: passing '25 December' for years 99 to 50 to new Date('25 December 50') ends up as 25 December 1950 to 1999, while passing '25 December' for years 49 down to 1 to new Date('25 December 1') ends up as 25 december 2001 to 2049.

Same issue occurs when using the other Date(year, month, day) constructor.

The Kata is using those incorrect result directly from JavaScript to pass the Kata Tests.

Eventually I managed to get my convoluted code to pass the test by applying the expected false logic.

The biggest flaw in this Kata is that Author states very clearly : "Note: calendar used in the kata is Gregorian."
The Gregorian Calendar only dates back as far as 1582 as is the main reason why you will get side-tracked and possibly try to compensate for it.

Even if using Gregorian calendar calulations for Year 0001, the 25th of December 0001 was actually a Sunday not a Tuesday as Javascript states :)

Ensure you are attacking this Kata with complete ignorance to calendars and ignoring all real dates just use Javascript output which the unit tests are written for!

Given the requirement of Gregorian dates, if the method is being called with any year lower than 1582 a unit test should verify that an exception is thrown as the specified date is not after 1582 as in accordance with the existance of the Gregorian calendar.

The expectations of this Kata are incorrect in the context of the real world but correct within the expectations of the JavaScript date object functionality.

Kata should be re-worded and any menioning of the Gregorian calendar should be removed as the unit tests for this Kata don't care either and simple take JavaScript Date object output as gosbel, hence so should you when trying to solve this Kata instead of gettign side tracked with calendar types.

Very very badly worded Kata no matter how much the Author is trying to justify it in the discussions!

This was something else.

Nice kata.

Was trying so many different ways to use .map() somehow but could not figure it out.
Not sure if it would be possible with Array.apply(this, {length: n}).map(function(){// magic here :)})

I'm sure my solution is awkwardly long but it passes the tests.

I'm confused though when I see other solutions not using this.state at all.
That would make me assume that .state is redundant as it is not really checked outside the object at all during the tests.