okay, i checked your code, you made the same mistake as me initially, rollback() has to support the entire history of versions, not just the last one. i think the description should make this clearer
The input will be in one of the following formats: "{MAJOR}", "{MAJOR}.{MINOR}", or "{MAJOR}.{MINOR}.{PATCH}"
This implies that major and/or minor are optional.
That anything after patch should be ignored can be viewed as a convenience (i.e. "we have the values we need, anything else doesn't break things so we'll just silently ignore it").
that's the thing with input validation in kata's, either it should be very clear, logical and consistent, or you should not have to deal with validation at all; this is in between, which is messy
i'd add that converting from an empty string to a default value, while there is already an overload / default argument to handle the case nicely, is awkward
please tag this as a question, not an issue. it is very likely that the error comes from your code, not the tests suite, as 160+ people passed the Java version without complaints. are you making sure that your methods are chainable ?
First of all this is a really nice Kata which I enjoyed, thanks for that! :)
Still cannot get it submitted (Java translation), although I think I have a rather stable implementation.
The random tests are always failing with smth like expected:<[53.4.63]> but was:<[VersionManager.patch()]>.
It appears to me as if there is some reflection magic at work, which does not seem correct.
Nice!
That's a good example of using EBNF.
Oops. Fixed, thanks!
Factor: “Should return f for valid parentheses” should read “Should return f for invalid parentheses” in tests and sample tests.
nice code, but calling rollback repeatedly will pop an empty stack eventually.
the description could make it clear that
rollback()has to support the entire history of versions, not just the last versionokay, i checked your code, you made the same mistake as me initially,
rollback()has to support the entire history of versions, not just the last one. i think the description should make this clearerOk I completely read over that part. Perhaps because of all those capz.
This implies that major and/or minor are optional.
That anything after
patchshould be ignored can be viewed as a convenience (i.e. "we have the values we need, anything else doesn't break things so we'll just silently ignore it").that's the thing with input validation in kata's, either it should be very clear, logical and consistent, or you should not have to deal with validation at all; this is in between, which is messy
i'd add that converting from an empty string to a default value, while there is already an overload / default argument to handle the case nicely, is awkward
I don't really like the argument validation.
1.his an expected error, but1.2.5.his not. At least, that is what I make out of the spec.please tag this as a
question, not anissue. it is very likely that the error comes from your code, not the tests suite, as 160+ people passed the Java version without complaints. are you making sure that your methods are chainable ?First of all this is a really nice Kata which I enjoyed, thanks for that! :)
Still cannot get it submitted (Java translation), although I think I have a rather stable implementation.
The random tests are always failing with smth like
expected:<[53.4.63]> but was:<[VersionManager.patch()]>.It appears to me as if there is some reflection magic at work, which does not seem correct.
Can you have a look?
has been approved
Loading more items...