Il est grand temps de laisser la théorie de côté. Je vous ai suffisamment parlé du Test Driven Development pour que vous rêviez de vous y frotter !
Et c'est précisément ce que nous allons faire dans ce chapitre !
Présentation de la nouvelle fonctionnalité
Les tennismen l'auront sans doute remarqué, notre façon de compter les scores n'est pas correcte. Ou plutôt, elle est incomplète ! Nous n'avons pas prévu le Tie Break.
Au tennis, gagner 6 jeux n'est pas suffisant pour remporter le set. Il faut aussi deux jeux d'écarts. Donc si on mène 6-4 le set est gagné, mais si on gagne 6-5, le set n'est pas terminé et il y a deux cas de figure :
Le joueur 1 gagne et on passe à 7-5. Le set est remporté par le joueur 1.
Le joueur 2 gagne et on pase à 6-6. Dans ce cas, on va jouer un ultime jeu pour départager les deux joueurs. Et ce jeu, on l'appelle le Tie Break.
Les règles du Tie Break sont différentes d'un jeu classique. Chaque balle jouée vaut un point. Le premier arrivé à 7 avec deux points d'écart gagne le jeu. S'il n'y a pas deux points d'écart, le jeu peut continuer jusqu'à ce que mort s'ensuive !
Je vous propose d'implémenter cette nouvelle fonctionnalité en TDD en suivant la méthodologie Red, Green, Refactor.
Place à la vidéo !
Exceptionnellement, la suite de ce chapitre n'est pas retranscrite textuellement. À la place, je vous propose une démonstration de live coding dans lequel vous me verrez développer la nouvelle fonctionnalité de A à Z en Test Driven Development !
En résumé
J'espère que vous avez apprécié cette démonstration et qu'elle vous a convaincu de la puissance du Test Driven Development ! Souvenez-vous de bien répéter le cycle Red Green Refactor sans oublier aucune étape. À chaque fois, l'objectif est de trouver le plus petit test possible qui permet d'avancer.
C'est un gros changement dans la façon de développer. N'hésitez pas à pratiquer le Test Driven Development le plus possible et vous finirez par vous demander comment vous faisiez avant !
