LOL jfc

Thank you.

A string. e.g. "Hello World" If input is anything other than a string, it should return null

Have you make sure it is a string before using a string's method?

No fixed test for countLetters(""). ( Invalidate my solution! ) No Example Tests. No random Submit Tests.

And this has been done a thousand times before. I'm not even going to collect links.

Needs some improvement.

Pretty decent. I'd suggest adding a note about the type check in the description.

And if you want to go the whole hog, you could add randomised tests, too! ^^

i can actually generate random characters of random length. I think I'm having trouble in visualizing what to expect when the test is written, if that makes sense.

1. i gave it a republish with some more tests, not quite randomized, but I added some edge cases. I honestly couldn't think of a way to generate random characters with varying lengths of different random words?

2. Cleaned up the description. got rid of the console.log dilema. added more syntactically correct solution

cool, thank you for all the great feedback! ill make ssome edits right now.

Your Kata needs more extensive test coverage to prevent easy cheap-cheat solutions and/or logically flawed solutions. The most common way to increase test coverage is through the inclusion of randomly generated test cases at runtime so please add these. The lack of test coverage in a Kata as an Issue is recognised as an official CW stance.

IMHO the Kata Description isn't very clear on what data type is expected to be returned by the function. Although I recognised the "d:1 e:1" format as an object immediately, less able users may be confused by the Description as that isn't actually 100% valid syntax. You should show an actual valid object when explaining the return value in the Description such as {d: 1, e: 1} or just state that an object with key-value pairs where the key is a lowercase letter in the string and the value is the number of occurrences of that letter should be returned.

If you intend to actually ban the use of console.log in the user solution (what? because you lied to the user in the Description about the challenge input and don't want the user to find out?), you should do it in the Test Cases itself instead of just stating in the Description that the function should not call console.log. That being said, I'm not sure why you would even want to ban console.log in the first place as I personally find it very helpful in debugging.