It should. Creating kata is an endeavour with a lot of pitfalls, and very little room for error when pushing Publish.

There is a lot more documentation now than four years ago, but it's still not for the faint of heart.

However, consider what you are doing: you are creating content that is then immediately part of CodeWars. The quality of that content had better satisfy high standards, or before you could blink your eyes CodeWars would be a mess. There is some room for improvement after publishing, but not a whole lot.

What a wholesome thread here. I haven't created any kata and this thread kinda scares me :/

It's fascinating how people can come up with solutions that involve little or even zero regular expression.

Nice kata to practice regex skill. I'd suggest enabling Node v12.x because useful regex features such as named grouping are not supported in Node v8.x.

There should be much more thorough testing with invalid phone numbers, as currently it's possible to pass with incomplete input validation.

From the description it is unclear if it is allowed for "separators" to be mixed within the same phone number.

• The examples in the description don't cover this point.

• The first sample test imply they can be mixed.

• But then the final tests don't seem ever to test for mix of separators.

Suggest clarifying this in the description.

It times out because your code takes too long to complete the random tests. Try and improve your solution to make it run faster.

It looks much better now. It's really challenging but it's fun as well :)

That's not an excuse for several major issues, but it is a reason of course. Yes, I can imagine. :] ( Which is why I solved more kata and spent more time on here before I created my first kata. Too late for you, you already jumped into the deep end. :P It's swim or sink now! )

I see you discovered table markup. :P For a lot of things however, proportional font plain text just isn't ideal, even tabling it doesn't really help, and you had apparently not yet discovered the backtick "`". I have taken the liberty of doing some more marking up. (You can see the exact changes in Revisions, so you can always revert to your version.)

You are still specifying lots of things in examples. I would not necessarily have done that, but I'll admit it gives you something to hang them on.

The layout could be a bit less wide and some headings could be a bit bigger, but it's a world of difference from that sheer wall of text. I hope it's still more readable now. :]

As you can imagine it's my first kata. I formatted the text, hope it is more readable now :)

Random tests look good (I haven't actually tried them out).

The description is now a blank wall of text; it could do with some structure and formatting (see Docs -> Codewars Platform -> Comment Markdown; this works in Description also).

Thank you both for the feedback.
I have changed something, I have added some random tests and specified in the description what to do exactly. Then I removed the check on the letters and added the check only on the prefixes.
Hope now it a bit better, let me know guys :)

Do you agree?

I do not.

Even when seriously attempting to compose a solution, I would in this case get away with filtering only on lowercase letters, because there are no tests with uppercase ones. I don't imagine that is intentional actually. I remember some kata with some odd phone numbers:

72 * 673639 * 2
52 * 50875 * 12
30 * 5 * 547604
3 * 05 * 547604
6235 * 1 * 5292

All of those seemed to be valid phone numbers (according to rules that remained, unfortunately, unspecified). Who's to say one of those doesn't show up in your database some day?

Complete, exact specifications and random tests to those specs mostly solve most of these problems. You can always restrict your input domain to whatever you want to (or are able to) test. It's a test for your reference solution as well! (I have found more than one reference solution with problems that should really have been caught in testing. For my own kata, I like to have a different example solution and reference solution, as radically different as I can think of. Doesn't always work out of course. :)

Edited to add: Was this the logic you had in mind for invalid telephone numbers? It passes your tests ..

without random tests you can then cheat and not have to write any business logic which would just be sad :(

If you need help with any random tests I can help you :)