That was fun to see develop! Relying on the fact that objects are not iterable is such an elegant solution, and removes the need to any kind of solution.txt checking.

Seems like a viable strategy for testing exclusive usage of map/filter/reduce and could easily extended to some/every/findIndex etc...

Is this the kind of problem that would be interesting to make a kata out of, or should this still stay as a kumite? I'm not sure what the community standards are for language-specific requirements to katas.

Confirmed that's the path now, and it works in kumite

I couldn't get fs.readFileSync('/home/codewarrior/solution.txt', 'utf8'); working - it said there was no such file. Is that just in Kumite? Or was I doing that wrong?

@JohanWiltink recommended potentially trying to do something with proxies if that's necessary. I think regexing for in solution.txt would probably be sufficient to point point people in the right direction.

Awesome suggestion on the kumite - here it is: https://www.codewars.com/kumite/601d98152dc61400086240a9?sel=601d98152dc61400086240a9

I see that this kata is marked as "retired" - do I need to do anything else to remove it while we work on the kumite?

✅

• Added random tests for each function
• Added instructions to the description
• Added chai.config.truncateThreshold = 0
• Added some boundary cases (empty inputs, cases where there would be 0 or empty array results)

I'll marked this as resolved for now even though there's still an open "This is not the correct way to test for use of certain methods anyway" comment. If anyone has a suggestion for a different way to test for the presence of .map that might be more appropriate, I'd be open to it.

While it's certainly unpleasant to get messages like this, @JohanWiltink raises fair points about the quality / test coverage, and I will improve those.

re: "Test for behaviour, not implementation" - I don't see many (any, really) refactoring exercises here, but in real life developers refactor code constantly. The "for loop => map/filter" is such a common refactor I thought it could be useful to have the practice. Does that kind of kata have a place here? The concept seems in-bounds, even if the execution is lacking.

re: "This is not the correct way to test for use of certain methods anyway" I think I see what you mean. I could pass things in that are not iterable, but do have a map or filter method, and assert that way. Was that what you were thinking?

For me the issue isn't so much novelty as volume. There are a lot of 8kyu problems that require users to put something into an array, determine if a number is even or odd, skip some elements of an array.

But I don't see very many where the inputs are objects and it requires some traversal.

I don't know the etiquette here - it seems like if it meets community quality standards, but is redundant, then it would just get downvoted (or, just not upvoted) and kind of fade away. But I guess if the community guidelines are "each kata should be unique" then I can kill this one.

Also deeply embarrassing.

You're like the Simon Cowell of Codewars - a little on the harsh side but not wrong 😀 Thank you for taking the time.

I froze the test inputs, fixed the quotes, and increased the number of random tests.

Doh! 🤦🏻‍♂️ - that's embarrassing. I'm sorry for wasting your time on that.

Fixed.

Thanks for reviewing 👍🏻

I had written a loop with expect statements within one example, and refactored it to generate more random examples.

I also froze all of the the inputs in the solution, and wasn't aware that input mutation was a thing to avoid here - thank you for finding that too.

As for the "no novelty" comment, not sure what to do about that 🤷🏻‍♂️. I think I'll mark this as resolved and let people downvote it into oblivion if that's true.