Re: developing kata as kumite - the best way to develop a kata is actually as a translation. That editor is even better - you can actually test your example tests! Unfortunately, the base language of a kata can never be in a translation. For any translated languages though, you can fork the translation, update it, approve that, and it'll overwrite the original translation. But doing it in a kumite is almost as good, as long as you don't need radically different example and submit tests.

Language specificity is not a problem.

You can develop your kata as a kumite. You can do the description, the solution, preloaded and the tests, then convert it to a kata and add an initial solution and example tests ( just copy over the submit tests and delete what you don't want. I usually have an exact copy of the example tests in the submit tests, under an it-header "example tests", anyway ).

As long as it's a kumite you, me and everybody who cares can fork it, solve it, shoot at it, improve the tests - but they don't get to downvote yet! :P

However, turning this into a kata - imagine what Alex ( FArekkusu ) is going to say. "A simple map/reduce/filter problem is not new." And he will be right. The testing will be new ( I've never seen this before! ), but the user task and the user solution will be just another simple map/reduce/filter my list kata. So no, I don't think it's a viable kata. I can't offhand think of a way to turn the testing into a kata either - that's the interesting part after all.

Besides, doing the interesting thing means you're forcing implementation instead of behaviour - that's not what a kata should be. People have tried again and again to make kata out of specific implementation requirements, and it seldom works.

Wwrong path. "/workspace/solution.txt". I thought I wrote that somewhere for you, but I can't find it now.

That's in kata - I hope it works in kumite also.

If you want people to use map, filter and reduce, specify that in the description.

There should be no need to give hints in tests. Lots of people don't read them anyway. They'll wake up only when they start actually failing tests. So fail them. Preferably with a good failure message, which in this case should probably come from the argument object. That's OK, we control that, so it can give appropriate messages when it's asked to do something we don't want it to do.