Python:

• new test framework to be used
• missing random tests

No random tests.

Coffeescript translation kumited. Have fun!

(JS)

• Description does not specify what to do with non-string input.
• The first Submit test cleverly generates its own expected error by calling expectError() with a non-function as its first argument.
• No random tests.

Oh.
My.
Goodness.

I implement a linked list and pass all the Example Tests. I leave .search() empty for now because it's completely unspecified what it should do and I am passing the tests anyway.

I then run the Submit Tests to see what more I should do (because it sure isn't in the Description).

I fail all of them, with TypeErrors which leave me mystified and error messages which leave me even more mystified because they are unapplicable. All of them? No, one test fails with an English error: "..remove either the head and [the] tail .."

Please provide full specifications in the Description.
Please provide Example Tests that actually indicate whether or not a solution is going in the right direction.
Please just use Submit Tests to extensively check all edge and corner cases, perhaps check for performance, and, using random tests, to prevent cheating.

I am passing all the Example Tests and I am failing all of the Submit Test categories. And I have not a clue what I am doing wrong.

These are not the makings of a good kata.

Minor issue, according to PEP8 (Python):

Function names should be lowercase, with words separated by underscores as necessary to improve readability.

mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.

def get_substrings(s):

Thanks for this kata!

Needs word. I think this Kata has potential, but the previous comments should probably be addressed. I would be great to include more test cases as well.

Some of the points have been made already, but I summarize them here, anyway:

• null and undefined are mixed in a strange way. You should either accept both or consistently use on or the other.

• search has a second parameter in the provided code that is never used.

• if the parameter to search is a function, that function takes a node as the parameter, not a value. You should probably mention this somewhere. (This is also the only place where a node is ever used outside of the linked list, which is a bit weird.)

I can buy that search returns the found value. If you pass in a function, this can make sense. The only problem is that you can never store undefined in a node, since you wouldn't know if it was found or not.

Other than that, I think it's a nice kata. :-)