Approved

python new test framework is required. updated in this fork

Ruby 3.0 should be enabled, see this to learn how to do it

Hmmm, I see what you are getting at.

I've updated the kata description to include the case with the empty entries. It's not great but I'll try and update the description later today to be more clear about what is expected for this particular problem :)

If I wrote about all possible edge cases, I would be here all they and no one would have to think about them.

Yes, of course we're not going to write all possible edge cases. But still, can you at least specify what edge cases are you expecting, and how do you expect them to be handled?

Think and guess are different things. If we have to contemplate what the kata author is thinking when he's writing the tests (as you're describing yourself right now), that's guessing, not thinking. And unless your sole intent is to make us guess (which is often not a good idea), you shouldn't make us guess.

If the input isn't what you expect, thrown an exception or an error. Simple as that.

Empty entries among a list of numbers are not expected too, and you expect us to drop them instead.

That's another form of guessing I guess.

I've updated the Kata test to warn about the possibility of having consecutive commas. I see how that could be unexpected.

Of course not. You have to decide when to stop. Or read the edge cases covered by the tests and only worry about those.

Why would you think that the string would contain non-numbers? or isn't a string, or anything else that isn't in the description? If the input isn't what you expect, thrown an exception or an error. Simple as that.

If I wrote about all possible edge cases, I would be here all they and no one would have to think about them.

The unit tests cover what I think is relevant for this kata and nothing more. The ones I don't show in the example are handled by the rest of the test cases, anything else doesn't matter (for this Kata obviously. If this was a real systems, I'm sure other things would need to be considered.)

As for the commas, I'm not enterely sure what you mean but that case is contemplated in the test cases. Infact that was one of the reasons that made me write this kata (this was actually a problem I had to solve in my day job)

The problem is, nobody knows how far the edge cases has to go. You didn't even define what does it mean for a test case to be edgy.

What if the input contains non-numbers?
What if the input isn't even a string?
What if the input has Unicode numerals?
What if someone destroyed all the built-in string methods?
What if I'm out of memory?
What if the interpreter explodes if my code length is bigger than, say, 50 bytes?

The rabbit hole goes on forever, and unless you tell us how far you'd delve into this, all we can do is pure guesswork. Having to bump against the actual test cases to discover additional, undocumented requirements is an issue.

Also, the semantics of comma-seperated values, unlike spaces, does not consider consecutive commas as one big separation. ,,,, in comma-separated values are perfectly valid (5 empty values, usually denoted as None/nil/undefined), so as an requirement that is not the natural choice.

Yes they do, but that is on purpose.
Programmers must always consider corner cases. This is my atempt to get people to think like that :)
I could put that in the description but I chose to ommit it. If the person doesn't consider them, then the test will catch it and the person will learn.

IMO, if you solve everything on the first try you don't learn much, and if you do, then you already know it anyway and that's the point :)

The change to show test cases include negative values is welcome. Correct me if I'm wrong but one of the test cases include an empty string. There is no indication that the test cases may include an empty string which greatly diminishines one's ability to solve the Kata from first attempt. You have to just guess and adjust your code to address this after the first attempt.

Can you elaborate?

The test cases cover all that :) And there are 100 more random tests that are automatically generated.

Also, this is python, so you don't need special handling for integer types so your solution can handle both cases whithout problems.

Anyway, this was my first kata so I apreciate the feedback. I'll update the description to include negative numbers.

poor description and limited sample tests in my opinion. No mention of weather the test cases include negative value or no stings at all.

Gladly, cheers.

Take a look at AcesOfGlory reply ;)

split(",") will return empty strings and trying to call int(s) where "s" is an empty string will throw that exception.

You can easily verify this on the python interpreter or a python script with this code: int("")

Ruby and Crystal are done however I don't see a translation to the javascript code :S

Could you submit again?