TDD : Bowling Game Kata

Le kata de code Bowling Game tel qu’il est présenté ici par Uncle Bob est une parfaite illustration des concepts du Test-Driven Development, notamment de la boucle red-green-refactor, et de la notion de baby steps.

Prenez d’abord connaissance du problème (première slide) et essayez de proposer une solution, en essayant d’utiliser l’approche TDD ou non (à votre convenance).

Parcourez ensuite l’ensemble du document et visualisez les différentes étapes du kata. Si besoin, reproduisez le kata dans votre IDE préféré.

 

A l’issue de cet exercice, vous devriez avoir remarqué un certain nombre de choses :

  • La partie tests apparaît à gauche de l’écran, la partie code applicatif à droite, ce qui est révélateur de l’importance des tests.
  • Le développement des tests et du code applicatif se fait conjointement, par allers-retours constants : on ne modifie l’un et l’autre que par petites touches.
  • L’auteur ajoute fréquemment des notes en haut à gauche des slides, correspondant à des points à améliorer. Ces notes débouchent sur des phases de refactoring (toujours lorsque les tests sont verts, conformément à la notion de refactor in the green).
  • Des commentaires sont régulièrement ajoutés, aussi bien sur les tests que sur l’implémentation. Ces commentaires sont présents de façon transitoire : ils indiquent que le code en lui-même n’est pas suffisamment clair et invitent ainsi à effectuer un refactoring. On note ainsi qu’au final le code ne contient pas de commentaire mais reste très lisible.
  • Le code du test reste clair est lisible. D’une certaine manière, le test reflète la spécification et peut éventuellement s’y substituer. Il est en effet plus immédiat de maintenir un test qu’un document de spécification.
  • A partir de l’énoncé, l’auteur propose une conception a priori qui met en oeuvre un diagramme de classe modélisant l’univers du domaine. Une fois le kata réalisé,  on s’aperçoit que l’implémentation repose sur une conception beaucoup plus simple (on est passé de 4 classes à une seule).   C’est ce qu’on appelle design émergent, parce qu’il ressort en appliquant l’approche TDD.

En guise d’exercices supplémentaires, ils existe quelques pistes d’amélioration de ce kata :

  • Dans l’implémentation, le nom de la variable frameIndex est peu clair ; proposez un nom plus approprié.
  • Le fait qu’à chaque tour le nombre de tirs est variable constitue une des difficultés majeures de l’exercice ; existe-t-il un moyen de rendre l’implémentation plus claire ?
  • Dans la solution proposée, on considère chaque tir séparément. Proposez une solution permettant de considérer l’ensemble de la partie sous forme d’une chaîne de caractère. L’exemple donné dans l’énoncé serait représenté de la façon suivante :
Game g = new Game();
g.play("14 45 6/ 5/ X 01 7/ 6/ X 2/6");

 

 

Laisser un commentaire