Apprends à tester tes exercices Pharo sur Exercism.
Dans sa forme la plus élémentaire, Exercism, ce sont avant tout les tests et la pratique des tests, car c'est ce qui fait avancer ton implémentation et te dit quand un exercice est terminé.
Pharo offre un excellent support pour travailler avec les tests, et pour les tests incrémentaux ! Tu peux lancer n'importe quel test d'un exercice en cliquant sur l'orbe situé à côté d'une classe de test ou d'une méthode de test.
Les orbes de test sont colorés selon le résultat de la dernière exécution des tests :
- vert en cas de réussite
- jaune en cas d'échec d'assertion
- rouge en cas d'erreur d'exécution ou d'exception
Des tests ordonnés
Les tests des exercices Exercism sont volontairement numérotés afin de définir un ordre d'exécution précis (par ex. test01_verifySomeProperty, test02_verifyAnotherProperty, etc.).
Quand tu travailles sur un exercice, il est recommandé de cliquer sur l'orbe du premier test, de comprendre l'échec et ce qu'il faut faire pour le faire passer, puis d'ajouter le code nécessaire à ta solution pour y arriver. En Pharo, il est tout à fait normal de faire ces modifications dans le débogueur, où tu as accès à la fois à l'éditeur de code et à une vue de toutes les variables et de tous les paramètres qui peuvent t'aider à comprendre le problème.
REMARQUE : ce n'est pas une pratique courante de préfixer les noms de tests par un numéro d'ordre, et tu ne dois PAS le faire quand tu écris des tests pour ton propre projet.
Ça tourne même quand c'est cassé
Pharo n'a aucun mal à s'exécuter avec du code cassé, et le débogueur se rouvre simplement dès qu'une erreur est rencontrée (une erreur de syntaxe, une valeur incorrecte, ou même une classe ou une méthode manquante). Cette technique a été l'une des principales sources d'inspiration du développement piloté par les tests, et tu peux en avoir un aperçu en lançant le premier test de n'importe quel exercice. Le débogueur va immédiatement t'indiquer que ta classe de solution est introuvable (puisque tu n'as encore rien écrit). Bonne nouvelle : un bouton « Create » t'aide à ajouter la classe manquante et à poursuivre l'exécution, jusqu'à ce qu'elle se termine ou qu'une autre erreur apparaisse.
Avec ton premier test, tu tombes ensuite sur une deuxième erreur, car tu n'as pas encore écrit de méthode. Là encore, le bouton « Create » du débogueur te permet d'en définir une et de continuer l'exécution. À ce stade, tu peux aussi cliquer plus bas dans la pile d'appels, examiner ce que le test en échec attend, et modifier ta nouvelle méthode pour le faire passer.
Aime le débogueur
Plus tard dans ton cycle de développement, il peut aussi être utile de cliquer plus haut dans la pile et d'utiliser le bouton « Restart » pour reprendre l'exécution du programme à un point antérieur, ce qui te permet ensuite d'avancer pas à pas dans ton programme pour voir ce qui se passe. C'est une façon importante et utile de comprendre pourquoi ton programme ne fonctionne pas.
En plus de voir les variables dans le débogueur, tu peux aussi sélectionner n'importe quelle instruction et cliquer sur inspect/print pour voir le résultat de son évaluation. C'est utile pour tester le résultat d'une méthode ou pour examiner l'état interne d'un objet.
N'oublie pas que tu peux aussi modifier du code en cours d'exécution dans le débogueur, et qu'enregistrer une modification fait simplement redémarrer l'exécution dans la méthode qui vient d'être enregistrée. Cela te permet d'expérimenter des modifications et d'en voir les résultats pendant que tu es encore dans le feu de l'action.
En résumé, n'aie pas peur d'utiliser le débogueur de Pharo : on le considère comme un outil précieux qui aide à comprendre un problème et à expérimenter.
Des groupes de tests plus grands et l'automatisation
Si tu as besoin de lancer des groupes de tests plus importants, tu peux aussi les exécuter depuis le menu Package, ou utiliser l'outil Test Runner (accessible depuis le menu World, ou en tapant <meta> + OU).
Tu peux aussi lancer les tests par programme depuis le playground, en évaluant l'expression avec print :
AllExercismTests suite run.
Si tu veux en savoir plus sur le fonctionnement interne des tests, tu peux te documenter sur SUnit ou parcourir le code de la hiérarchie TestCase.
Le savais-tu : le TDD a été inventé en Smalltalk avec l'introduction de la bibliothèque de tests SUnit
