Depuis quelque temps, je suis un maître en la matière de clean coding, Michaël Azerhad. Après une discussion et quelques vidéos suivies, je me lance dans la mise en œuvre. Le slack de sa société Wealcome a une communauté intéressante à suivre.
Le développement conduit par les comportements : voilà le sujet du jour. Pour faire suite à la série d’articles sur le redémarrage de mon projet, je vais vous parler de ce que j'ai compris de cette manière de coder.
Le but est d'écrire les tests qui permettent l'implémentation d’un scénario, dans une démarche de développement dirigé par les tests (Tests Driven Development).
➡ ️ On écrit le test, il passe au rouge. Logique, vu que rien n'est implémenté.
➡ ️ On écrit le code, et le test doit passer au vert.
➡ ️ Et on passe à la suite...
Pour revenir à notre développement du jour, une fois l’Event Storming fait, les premiers scénarios se dessinent. Nous en étions restés là.
Chaque colonne d'étiquettes va décrire un scénario, avec une matrice à suivre. L'étiquette jaune est la définition de l'état dans lequel est le système au moment du test. Ensuite le bleu représente les actions accompagnées de leurs contraintes, en vert.
Le langage utilisé pour ce travail, le gherkin, a été étudié de manière à être compréhensible aussi bien par les techniciens que les non-techniciens. Il suffit d'écrire ce scénario de la manière suivante :
"En tant que…" (Given en anglais), c'est le fameux état dans lequel doit être le système avant quelques actions que ce soit ;
"quand…" (When) l'action que l'on va tester ;
"alors…" (Then) retour du nouvel état du système.
C'est la matrice que j’évoquais précédemment.
Vu comme ça, c'est tout simple. 😊 Tout le monde peut comprendre ce que va faire le code.
Il ne reste plus qu'à l'implémenter. Beaucoup de langages de programmation peuvent fonctionner avec gherkin. L'API de mon projet étant en php, nous allons utiliser Behat pour interpréter ces tests.
L'avantage de cet outil, Behat, c'est qu'à la première exécution il va nous dire que rien n'est implémenté, et nous proposer le code pour un déroulement basique en fonction du scénario décrit.
Ne reste plus qu'à copier ce code, puis l’adapter afin de le faire passer au vert. 😊
L'avantage de cette technique, c'est de partir de zéro. Le test donne la direction à suivre pour le développement. Vous ne créez que les entités et services nécessaires. Pas besoin, pour un inventaire, de créer une entité fournisseur pour les articles. Cette implémentation n'est utile que pour une commande. (Dans le cas d'usage de mon projet)
Mon premier jet de code fonctionne, mais à y regarder correctement, je ne m'y prends pas comme il le faut. Oui, mon implémentation dans le code de Behat passe, mais je n'ai aucun code à présenter en dehors de mon test… 🤭
Le but n'est pas là. Je suppose que c'est un piège dans lequel la majorité des débutants doit tomber. Le code étant fonctionnel, je n'ai plus qu'à le mettre en place dans des classes et services qui pourront fonctionner avec le reste de l'application. L'avantage, c'est que je sais que mon raisonnement est correct pour un test vert.
A certains moments, le scénario est plus complexe, et nécessite d'être testé plus finement. On utilisera les tests unitaires pour ce faire. Dans le même dessin qu'avec gherkin, on écrit le test qui doit correspondre au développement attendu, qui passe au rouge, puisque rien n’est développé. Puis on écrit le code qui fera passer ce test au vert.
Cette technique de développement permet d'être mieux dirigé dans l'écriture du code, et de manière plus rapide. Seule la solution nécessaire est écrite, pour respecter le principe YAGNI. Et tout est testé au fur et à mesure de l'écriture du code. Si un code plante, il suffit de revenir à l'état juste avant son écriture, vu que les tests précédents sont verts. Et on sait que tout ce que l'on fera par la suite devra être testé de la même manière que le code déjà écrit.
La dernière phase est de prendre l’habitude de coder de la sorte, pour acquérir rapidité et assurance.
Pour la suite de mes articles, je prévois la mise en place du DDD (Domain Driven Development), le Développement Dirigé par le Domaine. Un vaste sujet, pour lequel il me reste du travail à faire.
Bon code !
Photo de KOBU Agency sur Unsplash