"TDD Xtrême"
Quentin Ducasse.
-Bonjour à tous.
Dans ce 2e Redo, on s'intéressera
au compteur qu'on a pu faire dans la 1re semaine,
mais on va utiliser un nouveau flot de développement.
On va commencer par définir les tests
et créer les méthodes jusqu'à ce que les tests soient verts.
Le débugger peut nous aider, car il peut créer les méthodes pour nous
et être suffisamment intelligent pour proposer une structure correcte.
D'abord, on va ouvrir notre System Browser.
Cliquez dans l'environnement Pharo.
Vous allez dans l'onglet Tools, puis System Browser.
Ensuite, on crée notre classe de test, donc "CounterTest",
qui sera une sous-classe de "TestCase" puisqu'on va écrire le test.
Le package, on va l'appeler "MyCounter". On sauvegarde, donc Cmd+S.
Ça nous crée le package.
On veut pas voir les autres packages donc on filtre tout ça.
Voilà. On a notre package avec notre classe de tests.
On va écrire directement notre premier test
qu'on va calquer sur celui qu'on avait écrit dans le premier Redo.
"CounterIsSetAndRead".
On crée une variable temporaire "c" qui va être notre compteur,
donc "Counter new".
Ensuite, on met son count à 7
et on vérifie que son count est bien à 7.
Donc, "count equals:7"
On n'a absolument rien défini, ni la classe, ni les accesseurs,
donc le setter "count:" ou le getter "count".
Mais on va quand même compiler en faisant Cmd+S et vous voyez...
Il me demande mon prénom. Très bien. OK.
La variable compteur n'a pas été reconnue.
On veut définir une nouvelle classe. On clique sur Définir une nouvelle classe.
Il propose une définition de classe, sous-classe d'objet, c'est bien.
Catégorie, donc le package MyCounter. Très bien. OK.
On voit que notre classe est apparue. Notre test aussi.
On peut cliquer pour exécuter le test.
Et on se rend compte qu'il n'a pas compris "count:".
C'est normal, on ne l'a pas défini.
Le débugger s'est ouvert.
On a notre pile d'exécution dans la fenêtre en haut.
On a la méthode sur laquelle il s'est arrêté,
avec, surlignée, la méthode qu'il n'a pas comprise.
En bas, on a les variables temporaires avec leurs valeurs associées.
On voit que "c" a la valeur "aCounter". Donc, ça n'a pas fonctionné.
Il suffit de cliquer sur Create, ici, pour qu'il définisse la méthode count.
On va la définir dans Compteur,
dans le protocole "accessing".
OK.
Il a créé le corps de méthode avec "self shouldBeImplemented".
C'est à remplacer.
On veut qu'il mette "anInteger" dans la variable d'instance count.
Sauf qu'elle est en rouge. Pourquoi ?
Car si on regarde ici, dans le compteur, on ne l'a pas définie.
Mais le débugger est assez intelligent pour faire ça pour nous.
On va sauvegarder notre corps de méthode.
Il va nous dire que la variable count n'est pas reconnue.
On ne veut pas définir une variable temporaire, mais une variable d'instance.
Il l'a définie. C'est redevenu bleu. On peut cliquer sur Proceed.
L'exécution du test s'est arrêtée
sur la deuxième méthode qu'on n'a pas définie, le getter,
qu'on va définir en cliquant sur Create.
On va le définir dans la classe Compteur.
C'est toujours dans le protocole "accessing".
OK.
Cette fois, il propose un getter qui est correct.
Donc, on n'a qu'à cliquer sur Proceed. On clique sur Proceed.
Le test est rouge, mais si on le réexécute, il sera vert.
Si on inspecte la classe Compteur, on peut voir
qu'on aura un protocole accessing,
une méthode count:, une méthode count.
Ça veut dire que tout a bien été créé,
malgré le fait qu'on a tout défini depuis le débugger.
Notre variable d'instance est bien intégrée aussi.
On va écrire un nouveau test.
Si vous vous souvenez bien,
on avait un test qui utilisait une méthode de classe.
On va la réécrire. Elle s'appelait "startingAt".
On pouvait lui donner un entier
et ça faisait commencer le compteur à l'entier qu'on lui donnait.
Donc, on va vérifier, en créant le compteur de cette méthode de classe,
qu'il est effectivement bien mis au bon entier.
On sauvegarde. Notre test est créé. La méthode n'est pas reconnue.
Ce n'est pas grave. On lance le test directement.
On verra qu'effectivement,
la méthode qui n'a pas été reconnue bloque l'exécution.
On veut la créer. On clique sur Créer.
On va la définir dans Counter class
et cette fois, le protocole sera "instance creation".
OK. "self shouldBeImplemented". Que veut-on faire ?
On veut définir un nouveau compteur, donc "c: Counter new."
qui commence à 5... "anInteger", pardon.
Qui commence à la valeur qu'on lui donne.
Et on veut qu'il nous rende ce "c". Très bien. On sauvegarde.
La méthode a été sauvegardée. On clique sur Proceed. Le test est vert.
La méthode n'est pas reconnue, car la fenêtre n'a pas été rafraîchie.
Si on clique ici, on voit que tous nos tests sont verts.
On va écrire un nouveau test
pour les méthodes "increment" et "decrement" qu'on a pu avoir.
On va faire : "c increment;increment." et on veut que ce soit égal à 7.
N'oubliez pas de changer le nom.
C'est "CounterIncrement".
On sauvegarde ça.
La méthode est créée. On va l'exécuter.
La méthode increment n'a pas été comprise
et c'est normal, car on ne l'a pas créée.
On va cliquer sur Create. On va la définir dans Compteur.
On va la mettre dans le protocole "operation".
OK.
"Increment". Que veut-on qu'increment fasse ?
On veut qu'increment, ça fasse : "count:=count+1".
Ce n'est pas plus compliqué que ça. On sauvegarde. Cmd+S.
En cliquant sur Proceed, on voit que notre test passe.
On va faire la même chose avec "decrement".
On va changer ça.
"Decrement".
"CounterDecrement" et on veut que ce soit égal à 3.
On sauvegarde.
On exécute le test.
La méthode decrement n'est pas comprise. C'est normal.
On clique sur Create.
On la définit dans Compteur sous le protocole "operation".
OK.
"Decrement" qui va enlever 1 à la variable d'instance "count".
Donc "count-1".
On sauvegarde.
On clique sur Proceed. Le test est vert.
Là, tous nos tests sont verts.
Et si on s'intéresse à la classe Compteur,
on voit que toutes nos méthodes ont été créées comme il faut.
Même la méthode de classe,
en cliquant sur Class side, on va bien avoir startingAt.
Le débugger est un outil très puissant dans Pharo.
Vous pouvez voir ici qu'on a créé des tests
qui sont déjà verts et déjà écrits.
Donc, notre classe fonctionne déjà comme on voulait qu'elle fonctionne.
Je vous encourage à penser de cette manière, Test Driven Development.
C'est un développement qui est conduit par le test.
Vous allez écrire votre test,
puis vos méthodes jusqu'à ce que votre test devienne vert.
Ce type de développement est encouragé dans Pharo,
car le débugger peut vous aider à accélérer la création de méthodes,
que ce soit des méthodes de classe,
la définition de variables d'instance, des accesseurs.
Donc, c'est vraiment encouragé.