TDD Rediscovered ProgrammerTests Exercise

The Exercise

The idea is to create a console application that can calculate the traditional score for a Ten-Pin Bowling game.

A game consists of ten frames.
A frame consists of two tries to knock down ten pins.
If the bowler knocks down less than ten pins, that is their score
if the bowler knocks down ten pins in two tries, this is a 'spare', and their score is ten + the pins knocked down in the first try from the next frame.
If the bowler knocks down ten pins in one try, this is a 'strike', and thier score is ten + the pins knocked down in the next frame
If the bowler gets a 'spare' on the last frame, they get an additional try, and their score is ten + the number of pins knocked down
If the bowler gets a 'strike' on the last frame, they get an additional two tries, and their score is ten + the number of pins knocked down
On any extra tries in the last frame, knocking all the pins down does not count as a 'spare' or a 'strike'

And some scope control

We are just calculating the final total, we don't calculate the score for intermediate frames
We do not check for valid rolls (i.e. -1 or 11)
We don't check the input for additional frames or rolls

For information, the score will be between 0 and 300.

The purpose of this kata is to experience the TDD approach whilst using the following rules:

We are writing Programmer Tests. A failing test tells us that the last edit to the source is the source of an issue
The prompt to write a test is a new requirement. We assume that we obtained these when elaborating the story with the customer.
When we discover that we need new collaborators by refactoring we ask: are they part of our public interface or an implementation detail. We don’t test implementation details