Le kata du « Bowling Game »

L’objectif de cet exercice est d’implémenter un composant qui calcule le score d’une partie de bowling américain.

Une partie se déroule en 10 tours. À chaque tour, le joueur dispose de deux essais pour faire tomber 10 quilles disposées en triangle. Le score de base est le nombre de quilles que le joueur a réussi à faire tomber pendant le tour.

Lorsque le joueur arrive à faire tomber les dix quilles en deux lancers, cela s’appelle un spare. Le score d’un spare est de 10, auquel on ajoute le nombre de quilles tombées au lancer suivant.

Lorsque le joueur arrive à faire tomber les dix quilles en un seul lancer, cela s’appelle un strike. Le score d’un strike est de 10, auquel on ajoute le total de quilles tombées aux deux lancers suivants.

Lors du dernier tour :

• si le joueur réalise un spare, il dispose d’un lancer bonus pour permettre de calculer son score ;
• si le joueur réalise un strike, il dispose de deux lancers bonus pour permettre de calculer son score.

Cela signifie qu’une partie de bowling se termine en 21 lancers maximum (10 spare d’affilée).

Le composant que l’on cherche à implémenter n’est pas responsable de valider le nombre de coups joués dans une partie ni que les coups sont "légaux". On part de l’hypothèse que cette validation est réalisée avant d’interagir avec ce composant, et donc qu’il sera systématiquement appelé avec une entrée bien formée.

C’est pour cette raison que l’on se moque de connaître la solution et qu’il est bon de répéter ce kata quotidiennement (mais pas plus d’une fois par jour) : le plus important est d’être capable d’y parvenir en réalisant délibérément chaque geste, de manière à mémoriser les questions que l’on se pose plutôt que les réponses que nous leur apportons.

Le principe du TDD est de boucler rapidement sur les trois étapes suivantes :

1. RED : On écrit le minimum de tests possible pour que les tests échouent,
2. GREEN : On ajoute le code le plus simple possible pour faire passer tous les tests,
3. REFACTOR : C’est ici que l’on prend soin du code et que l’on peut factoriser ou renommer les choses, les tests garantissent que nous ne casserons pas le travail que nous avons déjà fait.

Mais la toute première chose à faire est de créer un environnement (ou "projet") pour travailler.

Dans mon cas, je vais réaliser ce kata en Go, et je vais donc taper les lignes suivantes :

$ rm -rf ./bowling && mkdir bowling && cd bowling
$ go mod init bowling

Puis je vais ouvrir mon éditeur (vim) dans lequel je vais créer un fichier dans lequel je vais écrire mon premier test.

Le premier élément d’interface auquel nous ayons à faire est le constructeur. C’est pourquoi j’ai écrit le test suivant dans un fichier bowling_test.go.

package bowling

import "testing"

func TestNewGame(t *testing.T) {
    game := NewGame()
    if game == nil {
        t.Fatal("NewGame() returned nil")
    }
}

Évidemment, ce test ne compile pas puisqu’il fait appel à la fonction NewGame() qui n’est pas définie. Nous pouvons d’ailleurs le vérifier dans la console (dans la réalité j’utilise la commande :GoTest dans Vim) :

$ go test
# bowling [bowling.test]
./bowling_test.go:6:10: undefined: NewGame
FAIL    bowling [build failed]

Nous sommes donc à l’état RED. Notre mission est d’écrire juste ce qu’il faut de code pour que ce test passe au vert. Je vais écrire ce code dans le fichier bowling.go que voici :

package bowling

type Game struct{}

func NewGame() *Game {
    return new(Game)
}

Je relance les tests. Ils passent avec succès : nous sommes GREEN. C’est l’heure de "refactoriser", sauf qu’il n’y a rien à refactoriser pour l’instant, donc notre but est d’écrire un nouveau test qui échoue.

Dans notre cas, nous voulons calculer un score de bowling. Nous savons qu’une partie de bowling se compose d’un nombre variable de lancer et nous savons que nous ne calculerons le score que de parties finies. Nous savons aussi que nous ne passerons aucune donnée invalide à notre composant.

La partie la plus simple possible au bowling est une partie nulle (on envoie la boule dans la gouttière à chaque coup). C’est pourquoi j’ai rajouté le test suivant dans bowling_test.go pour la simuler.

package bowling

import "testing"

func TestNewGame(t *testing.T) {
    game := NewGame()
    if game == nil {
        t.Fatal("NewGame() returned nil")
    }
}

func TestGutterGame(t *testing.T) {
    game := NewGame()
    if game == nil {
        t.Fatal("NewGame() returned nil")
    }
    for i := 0; i < 20; i++ {
        game.Roll(0)
    }
    score := game.Score()
    if score != 0 {
        t.Fatalf("game.Score() should be 0, got %d.", score)
    }
}

Évidemment, ce test ne compile pas, car il utilise 2 méthodes qui ne sont pas définies :

• game.Roll(int) qui sert à enregistrer un lancer,
• game.Score() int qui sert à récupérer le score final.

Bien qu’il ne compile pas, ce test m’a poussé à réfléchir aux fonctions que je vais écrire. C’est l’API la plus simple possible.

Nous voici donc à nouveau à l’état RED. Il suffit de définir ces méthodes pour que le test passe :

package bowling

type Game struct{}

func NewGame() *Game {
    return new(Game)
}

func (g *Game) Roll(pins int) {}

func (g *Game) Score() int {
    return 0
}

Je relance les tests. Ils passent : nous sommes GREEN.

Regardons nos tests : le test TestNewGame est entièrement contenu dans le test TestGutterGame. Autrement dit, si ce dernier échoue, TestNewGame ne nous donnera aucune information supplémentaire. Ce test est donc redondant : il faut le supprimer. Ce que l’on peut faire, par contre, c’est factoriser ce code dans une fonction newGame afin de ne pas avoir à récrire cette vérification à chaque test que nous écrirons :

func TestGutterGame(t *testing.T) {
    game := newGame(t)
    for i := 0; i < 20; i++ {
        game.Roll(0)
    }
    score := game.Score()
    if score != 0 {
        t.Fatalf("game.Score() should be 0, got %d.", score)
    }
}

func newGame(t *testing.T) *Game {
    game := NewGame()
    if game == nil {
        t.Fatal("NewGame() returned nil")
    }
    return game
}

Du reste, il n’y a pas de code à bouger, mais il est idiomatique en Go de documenter toutes les fonctions et types publics (dont le nom commence par une majuscule) que nous créons, en écrivant pour cela des commentaires spéciaux, sans quoi golint nous fera les gros yeux. Faisons ça dès maintenant pour ne pas avoir à y repenser plus tard.

package bowling

// A Game models a single bowling game and allows to compute its end score.
type Game struct{}

// NewGame creates a new Game.
func NewGame() *Game {
    return new(Game)
}

// Roll records the number of pins that went down during a single roll.
func (g *Game) Roll(pins int) {}

// Score computes the score of the game.
func (g *Game) Score() int {
    return 0
}

Et voilà, le projet est démarré.

Il est temps d’écrire un nouveau test.

Jusqu’à présent, nous avons réalisé une partie où on ne tombait aucune quille à chaque coup. Essayons maintenant une partie où nous tombons une seule quille à chaque fois. Cette partie devrait être composée de 20 lancers, et son score final devrait être 20.

Pour ce faire, j’ai copié-collé notre premier test puis je l’ai modifié pour donner ceci :

package bowling

import "testing"

func TestGutterGame(t *testing.T) {
    game := newGame(t)
    for i := 0; i < 20; i++ {
        game.Roll(0)
    }
    score := game.Score()
    if score != 0 {
        t.Fatalf("game.Score() should be 0, got %d.", score)
    }
}

// XXX copy-pasta
func TestAllOnes(t *testing.T) {
    game := newGame(t)
    for i := 0; i < 20; i++ {
        game.Roll(1)
    }
    score := game.Score()
    if score != 20 {
        t.Fatalf("game.Score() should be 20, got %d.", score)
    }
}

Sauf que l’on n’en est pas à l’étape où on refactorise les choses. C’est pour cette raison que j’ai laissé ce commentaire // XXX copy-pasta. Mon éditeur va faire ressortir ce XXX avec un fond coloré pour attirer mon attention et ne pas l’oublier quand il sera temps de refactoriser.

En attendant, les tests échouent, évidemment :

bowling_test.go|30| game.Score() should be 20, got 0.

Il va donc falloir faire passer ce test. La solution la plus simple est d’accumuler le score dans un attribut de la structure Game :

package bowling

// A Game models a single bowling game and allows to compute its end score.
type Game struct {
    score int
}

// NewGame creates a new Game.
func NewGame() *Game {
    return new(Game)
}

// Roll records the number of pins that went down during a single roll.
func (g *Game) Roll(pins int) {
    g.score += pins
}

// Score computes the score of the game.
func (g *Game) Score() int {
    return g.score
}

Les tests passent, nous sommes GREEN. C’est maintenant que l’on refactorise nos tests.

Pour cette raison, factorisons les trois étapes de chaque test :

• initialisation (newGame(t) fait déjà le travail),
• exercice du code (lancer game.Roll() dans une boucle),
• vérification (comparaison de game.Score() avec la valeur attendue).

Voici ce que cela donne chez moi :

package bowling

import "testing"

func TestGutterGame(t *testing.T) {
    game := newGame(t)
    rollMany(game, 0, 20)
    checkScore(t, game, 0)
}

func TestAllOnes(t *testing.T) {
    game := newGame(t)
    rollMany(game, 1, 20)
    checkScore(t, game, 20)
}

func newGame(t *testing.T) *Game {
    game := NewGame()
    if game == nil {
        t.Fatal("NewGame() returned nil")
    }
    return game
}

func rollMany(game *Game, pins, count int) {
    for i := 0; i < count; i++ {
        game.Roll(pins)
    }
}

func checkScore(t *testing.T, game *Game, expected int) {
    score := game.Score()
    if score != expected {
        t.Fatalf("Score should be %d, got %d.", expected, score)
    }
}

Ça y est, vous êtes bien échauffés ?

Il faut maintenant que notre code soit capable de compter des spares. Pour cela, écrivons un test qui réalise un spare (6, puis 4 quilles) et un lancer non-nul (3 quilles), puis une partie nulle le reste du temps. Le score du spare devra être (6 + 4) + 3 = 13, et le core total 13 + 3 = 16.

func TestOneSpare(t *testing.T) {
    game := newGame(t)
    game.Roll(6)
    game.Roll(4)
    game.Roll(3)
    rollMany(game, 0, 17)
    checkScore(t, game, 16)
}

Et bien sûr ce test échoue avec le message : Score should be 16, got 13.

C’est maintenant que nous allons devoir nous gratter la tête. Commençons par jeter un oeil un peu plus critique à nos méthodes :

// Roll records the number of pins that went down during a single roll.
func (g *Game) Roll(pins int) {
    g.score += pins
}

// Score computes the score of the game.
func (g *Game) Score() int {
    return g.score
}

Nous avons :

• une méthode dont le nom et la documentation indiquent qu’elle enregistrent les coups, alors qu’elle calcule le score,
• une méthode dont le nom et la documentation indiquent qu’elle calcule le score, alors qu’elle ne fait rien si ce n’est retourner le score déjà calculé.

Ceci est indicatif d’un problème de design. Nous allons donc avoir besoin de faire des changements relativement profonds dans notre code, alors commençons par commenter le test TestOneSpare, afin de retourner à l’état GREEN précédent, et pouvoir changer de design tout en nous assurant que notre code fonctionne au moins aussi bien qu’avant.

Au lieu de ne garder que le score final en mémoire, nous devrions garder chaque coup, puis calculer le score final dans la méthode. En Go, on peut faire cela avec une slice d’entiers, dont la capacité maximale, 21 éléments, est connue dès le départ.

En modifiant mon code ainsi, le code passe à nouveau tous les tests (sauf TestOneSpare, oui) :

package bowling

// A Game models a single bowling game and allows to compute its end score.
type Game struct {
    rolls []int
}

// NewGame creates a new Game.
func NewGame() *Game {
    return &Game{make([]int, 0, 21)}
}

// Roll records the number of pins that went down during a single roll.
func (g *Game) Roll(pins int) {
    g.rolls = append(g.rolls, pins)
}

// Score computes the score of the game.
func (g *Game) Score() (score int) {
    for _, roll := range g.rolls {
        score += roll
    }
    return
}

Je peux maintenant décommenter TestOneSpare et revenir à l’état RED.

Pour gérer les spares, maintenant, nous avons besoin de compter le score de la même façon que nous comptons manuellement les points au bowling, en considérant la partie comme 10 tours ayant chacun un nombre variable de lancers.

Voici comment je passe GREEN :

// Score computes the score of the game.
func (g *Game) Score() (score int) {
    var i int
    for turn := 0; turn < 10; turn++ {
        if g.rolls[i]+g.rolls[i+1] == 10 { // spare
            score += g.rolls[i] + g.rolls[i+1] + g.rolls[i+2]
        } else { // regular
            score += g.rolls[i] + g.rolls[i+1]
        }
        i += 2
    }
    return
}

Autrement dit, à chaque tour, je regarde si le tour est un spare ou non. S’il l’est, il compte comme la somme des deux lancers du tour courant et du prochain lancer, sinon, il compte normalement comme la somme des quilles tombées en deux coups.

Admettons que ce code n’est pas très lisible. Ça tombe bien, parce que c’est le moment de le refactoriser. D’abord, cette variable i n’est pas super bien nommée parce qu’on ne sait pas vraiment à quoi elle fait référence. Elle est utilisée pour être un indice dans le tableau de lancers, je me propose donc de la renommer rollIndex.

Ensuite, ces calculs polluent un peu la compréhension du code. Plutôt que d’expliquer que nous comptons des spares ou des coups réguliers dans des commentaires, faisons du code qui se documente tout seul en extrayant ces calculs dans des méthodes dont le nom est explicite. Voici ce que ça donne.

// Score computes the score of the game.
func (g *Game) Score() (score int) {
    var rollIndex int
    for turn := 0; turn < 10; turn++ {
        if g.isSpare(rollIndex) {
            score += g.countSpare(rollIndex)
        } else {
            score += g.countRegular(rollIndex)
        }
        rollIndex += 2
    }
    return
}

func (g *Game) isSpare(rollIndex int) bool {
    return g.rolls[rollIndex]+g.rolls[rollIndex+1] == 10
}

func (g *Game) countSpare(rollIndex int) int {
    return g.rolls[rollIndex] + g.rolls[rollIndex+1] + g.rolls[rollIndex+2]
}

func (g *Game) countRegular(rollIndex int) int {
    return g.rolls[rollIndex] + g.rolls[rollIndex+1]
}

C’est tout de même plus facile à suivre, vous ne trouvez pas ?

Essayons un autre test avec les spares, maintenant, en faisant tomber 5 quilles à chaque lancer. Chaque tour va être un spare, et le dernier tour sera composé de 3 lancers. Le score final devrait être de 10 * (10 + 5), soit 150.

func TestAllFives(t *testing.T) {
    game := newGame(t)
    rollMany(game, 5, 21)
    checkScore(t, game, 150)
}

Et… ce test passe tout seul, donc on en a fini avec les spares !

Nous entamons la dernière partie du kata. Il faut maintenant que nous soyons capables de prendre en compte les strikes. Et pour cela nous allons… ?

Écrire un nouveau test, bien sûr !

Nous allons réaliser un strike, puis tomber successivement 4 et 3 quilles au prochain tour, puis complètement rater les 8 tours (16 lancers) suivants. Le score du strike devrait être 17, le score total de la partie devrait donner 24.

func TestOneStrike(t *testing.T) {
    game := newGame(t)
    game.Roll(10)
    game.Roll(4)
    game.Roll(3)
    rollMany(game, 0, 16)
    checkScore(t, game, 24)
}

Et ce test… échoue avec un débordement d’indice : panic: runtime error: index out of range [19] with length 19.

Ce n’est pas une grande surprise : un strike est un tour qui se joue en un lancer. Notre code ne sait pas gérer ce genre de tours. Apprenons-lui :

// Score computes the score of the game.
func (g *Game) Score() (score int) {
    var rollIndex int
    for turn := 0; turn < 10; turn++ {
        if g.rolls[rollIndex] == 10 {
            score += g.rolls[rollIndex] + g.rolls[rollIndex+1] + g.rolls[rollIndex+2]
            rollIndex++
        } else if g.isSpare(rollIndex) {
            score += g.countSpare(rollIndex)
            rollIndex += 2
        } else {
            score += g.countRegular(rollIndex)
            rollIndex += 2
        }
    }
    return
}

Nous sommes GREEN à nouveau. Procédons à la refacto :

• Comme pour les spares, isolons les calculs dans des méthodes aux noms explicites,
• En Go spécifiquement, cette suite de if {} else if {} else peut se récrire avec un switch qui sera plus lisible.

// Score computes the score of the game.
func (g *Game) Score() (score int) {
    var rollIndex int
    for turn := 0; turn < 10; turn++ {
        switch {
        case g.isStrike(rollIndex):
            score += g.countStrike(rollIndex)
            rollIndex++
        case g.isSpare(rollIndex):
            score += g.countSpare(rollIndex)
            rollIndex += 2
        default:
            score += g.countRegular(rollIndex)
            rollIndex += 2
        }
    }
    return
}

func (g *Game) isStrike(rollIndex int) bool {
    return g.rolls[rollIndex] == 10
}

func (g *Game) countStrike(rollIndex int) int {
    return g.rolls[rollIndex] + g.rolls[rollIndex+1] + g.rolls[rollIndex+2]
}

Voilà, un beau code bien propre. Nous pouvons maintenant écrire un dernier test, qui compte ce qui se passe lorsque l’on réalise une partie parfaite, c’est-à-dire, 10 strikes de suite, puis deux lancers "bonus" parfaits. Le score final d’une partie parfaite est 10 * (10 + 10 + 10) = 300.

func TestPerfectGame(t *testing.T) {
    game := newGame(t)
    rollMany(game, 10, 12)
    checkScore(t, game, 300)
}

Et… ce test passe avec succès, donc nous n’avons plus rien à faire. Mission accomplie.