I don't think you're necessarily missing anything, I just think you're looking at it from a different perspective. To me, the whole point of a kata is to learn the patterns and movements so that when they come up in production code you can make good refactors almost by second nature. For example, the key refactor to learn from Uncle Bob's solution to that kata in my opinion is when he moves the score calculation to happen in the score() method instead of calculating it on the fly in roll().
As for your first problem, you may be right if your goal is to follow TDD to the letter. I've never looked at it that way, however. To me, it's more of a gut thing. Sometimes you can caught up by trying to follow TDD too strictly.
For your second problem, it may make sense to break out a Frame class or it may not. To me, the solution is simple and understandable enough without it, but that's just my opinion.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't think you're necessarily missing anything, I just think you're looking at it from a different perspective. To me, the whole point of a kata is to learn the patterns and movements so that when they come up in production code you can make good refactors almost by second nature. For example, the key refactor to learn from Uncle Bob's solution to that kata in my opinion is when he moves the score calculation to happen in the
score()method instead of calculating it on the fly inroll().As for your first problem, you may be right if your goal is to follow TDD to the letter. I've never looked at it that way, however. To me, it's more of a gut thing. Sometimes you can caught up by trying to follow TDD too strictly.
For your second problem, it may make sense to break out a Frame class or it may not. To me, the solution is simple and understandable enough without it, but that's just my opinion.