Recently, I've gone through Uncle Bob's bowling scoring kata a couple times (http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata), and... I'm extremely disappointed with his solution. There are two big issues I have with his solution that I would like some feedback on.
Problem 1 (TDD): The third and fourth tests are garbage.
The way I understand it, and the way I've practiced it, when you're doing TDD, you make your test pass with the simplest possible code, and if the simplest code to make a test pass is some very stupid code, then you need to either write a better test or write more tests. For his third test to test spares (and he does the same thing for strikes), he is testing the scoring of spares by making a game where the first two frames are [5,5][3,0] with the remaining frames being all zeroes. He proceeds to take this and go on to write the code for scoring spares, but... the simplest code to solve this is "if roll == 3 then score += 3." Now, that's some dumb code, and you don't want to actually put that in, but that doesn't mean you just ignore it and go on to write the code you're trying to get to. It means you stop and write a better test, whether that means making a more complex game with multiple spares or whatever other thing you might have. Am I missing something here?
Problem 2 (OOD): How is it that he never breaks out a Frame class?
When I look at the Game class, and I see that all 5 of its private methods are passed in the exact same thing, a reference to every other roll (the start of a frame), it seems very straightforward to me that a Frame class needs to be broken out. The Frame just needs to be given its rolls and told about the next Frame, then it can return a score, which the Game class can then sum.
So... what am I missing here that makes these things actually make sense?
Top comments (1)
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.