Any seasoned programmer who has tried doing Test-Driven Development (TDD) knows that it is a completely different paradigm of development from traditional methods. So for most of us, it takes a lot of practice to become proficient at TDD. This kata provides a simple exercise to practice the 3 basic laws of Test-Driven Development.
Following is a suggested high-level design for this application. However, as you apply the laws of TDD, don't get hung up on following this design. Let this serve as a starting point and provide some basic vocabulary for your application. It's okay if your code takes you down a separate path from this design. That often happens with TDD, which is exactly how good architectures evolve.
Start with a Game class, which has two methods: Roll and Score. The Roll method take the number of pins knocked down for a given game. The Score method is called at the end of the game and returns the score of the game. Next is the Frame class — and a Game has 10 frames. The Frame class has one function, Score, which returns the score for a given frame. However, in the case of a spare or strike, the Score function will need to look ahead to the next frame to score the current frame — we therefore have the reference for the frame object back onto itself, indicating that dependency. Next is the Roll class, and a Frame has 1 or 2 Rolls, except in the tenth frame, where it will have 2 or 3 rolls — as indicated by the sub-type Tenth Frame, which has one additional role (as indicated). The Roll class has a private attribute of pins which holds the number of pins knocked down on a given roll.
- Write no production code except to pass a failing test.
- Write only enough of a test to demonstrate a failure.
- Write only enough production code to pass the test.
This is a kata that is borrowed from Bob Martin, who often uses this example to teach the practice of Test-Driven Development.