Test Driven De­ve­lop­ment (TDD) : comment ça marche ?

Avec la com­plexi­fi­ca­tion constante des pro­grammes in­for­ma­tiques, les méthodes agiles du Test Driven De­ve­lop­ment (TDD) sont de plus en plus pri­vi­lé­giées. Il y a de bonnes raisons à cela : grâce au TDD, les pro­gram­meurs s’assurent que le design d’un logiciel est bien pensé avant de commencer à écrire le code. Cette procédure augmente non seulement con­si­dé­ra­ble­ment la qualité du logiciel, mais réduit aussi les frais de main­te­nance.

Le dé­ve­lop­pe­ment piloté par les tests est par­ti­cu­liè­re­ment utilisé dans l’extreme pro­gram­ming, car il se distingue par des examens, des tests, une con­cep­tion et une refonte en continu. Les méthodes de Test Driven De­ve­lop­ment suivent un cycle de dé­ve­lop­pe­ment dont l’ordre doit être respecté afin de garantir son ef­fi­ca­cité.

Il existe depuis longtemps dif­fé­rentes méthodes per­met­tant de contrôler la qualité des logiciels. Au tout début du dé­ve­lop­pe­ment de logiciel déjà, des pro­grammes in­for­ma­tiques de test in­dé­pen­dants du secteur de la gestion de qualité en vé­ri­fiaient les fonc­tion­na­li­tés. Le dé­ve­lop­pe­ment concret des logiciels et le test de ceux-ci étaient encore con­si­dé­rés comme des processus in­dé­pen­dants l’un de l’autre. L’approche Test-First a d’abord été dé­ve­lop­pée par Kent Beck, dé­ve­lop­peur de logiciels américain et fondateur de l’Extreme Pro­gram­ming. Celui-ci a tout sim­ple­ment inversé le processus utilisé jusque-là : au lieu de commencer par écrire le code source et de le tester ensuite, l’équipe de dé­ve­lop­peurs commence par écrire le test. Puis les scénarios de test sont utilisés pour écrire et im­plé­men­ter le meilleur code possible.

Même si le dé­ve­lop­pe­ment basé sur des tests peut, au premier abord, sembler contre-intuitif pour un profane, il est logique et conduit à de meilleurs résultats. Tandis que les pro­cé­dures con­ven­tion­nelles de test en aval utilisent un modèle en cascade ou en v, les processus du TDD sont cycliques. Cela signifie que vous devez d’abord dé­ter­mi­ner les cas tests qui échouent fré­quem­ment. Cela est fait exprès, car dans la deuxième étape, vous n’écrivez que la quantité de code né­ces­saire pour réussir le test. Les com­po­sants sont ensuite remaniés : tout en con­ser­vant ses fonctions, vous étendez le code source ou le res­truc­tu­rez si né­ces­saire.

Le Test Driven De­ve­lop­ment s’oriente vers les résultats des scénarios de test conçus par vous. La procédure cyclique garantit que le code n’est transféré au système de pro­duc­tion que lorsque le logiciel répond à toutes les attentes. Cela signifie que vous refaites et testez à nouveau les com­po­sants du code jusqu’à ce que le test réussisse. Cette méthode vous permet d’enrichir le logiciel de nouvelles fonctions étape par étape, car vous écrivez un nouveau code source après chaque test réussi. Pour cette raison, le TDD est également considéré comme l’un des modèles de dé­ve­lop­pe­ment in­cré­men­tal dans le dé­ve­lop­pe­ment de logiciels.

Les scénarios in­di­vi­duels de test ne passent gé­né­ra­le­ment que quelques secondes ou minutes dans le cycle. Ainsi, les résultats sont ra­pi­de­ment visibles dans le code de pro­duc­tion. Pour que l’itération se fasse sans effort sup­plé­men­taire, vous avez besoin d’un outil et d’un framework TDD. Gé­né­ra­le­ment, les dé­ve­lop­peurs utilisent un outil de moteur d’in­té­gra­tion comme Crui­se­Con­trol ou Jenkins. Cela permet d’assurer l’in­té­gra­tion des com­po­sants en continu et sans erreurs dans le code source. JUnit, Maven ou Ant sont également po­pu­laires pour le dé­ve­lop­pe­ment en Java. En général : les tests sont écrits dans le même langage que le code de fonction. Ceedling ou Cmock font partie des outils dis­po­nibles pour le PHP.

Mais comment se déroulent exac­te­ment ces pro­cé­dures de test ? Le cycle que suivent les dé­ve­lop­peurs dans le cadre du Test Driven De­ve­lop­ment est également appelé la méthode du Red, Green, Refactor. Il s’agit des dif­fé­rentes phases qui doivent être res­pec­tées pour garantir une ef­fi­ca­cité maximale :

1. Phase rouge : dans cette phase, vous vous mettez à la place de l’uti­li­sa­teur. Celui-ci veut pouvoir utiliser sim­ple­ment le code. Vous écrivez donc un test, qui contient des com­po­sants qui n’ont pas encore été im­plé­men­tés. Vous devez décider quels éléments sont réel­le­ment in­dis­pen­sables pour que le code soit fonc­tion­nel.
2. Phase verte : supposons que le test échoue et qu’il est marqué en rouge. Vous endossez main­te­nant le rôle du pro­gram­meur et essayez de trouver une solution simple. Attention : n’écrivez que le strict né­ces­saire. Vous l’intégrez dans le code de pro­duc­tion afin que le test soit marqué en vert.
3. Re­fac­to­ring : dans cette étape, le code de pro­duc­tion est lit­té­ra­le­ment « rangé » et sa structure améliorée. Cela signifie que vous devez le compléter et le res­truc­tu­rer pour qu’il soit élégant et com­pré­hen­sible du point de vue du dé­ve­lop­peur. Par exemple, supprimer la du­pli­ca­tion des codes et atteindre un niveau pro­fes­sion­nel.

Veillez à ce que les dif­fé­rentes activités ne se che­vauchent pas. Cela signifie que vous n’écrivez pas de tests dans les phases 2 et 3, ni de code de pro­duc­tion dans les phases 1 et 3. Dans la vidéo suivante, vous pouvez voir comment fonc­tionne en pratique le dé­ve­lop­pe­ment piloté par les tests :

Le Test Driven De­ve­lop­ment est une stratégie de con­cep­tion, qui guide le processus de dé­ve­lop­pe­ment d’un logiciel au moyen de dif­fé­rents tests. Con­trai­re­ment aux processus en aval, les scénarios de test de la méthode TDD sont effectués dès le début de la con­cep­tion du logiciel. Les tests utilisés dans le contexte du TDD diffèrent par leurs objectifs et leurs portées. Le test le plus simple est le test unitaire, unit test en anglais. Il est utilisé pour tester les com­po­sants in­di­vi­duels d’un programme in­for­ma­tique. Les tests d’in­té­gra­tion et fonc­tion­nels qui per­met­tent de vérifier l’in­te­rac­tion des dif­fé­rentes parties du système et la fonc­tion­na­lité globale d’un logiciel sont plus complexes.

Depuis quelques années le Behavior Driven De­ve­lop­ment (BDD), également appelé pro­gram­ma­tion pilotée par le com­por­te­ment, se développe. Dans ce cas, l’équipe de dé­ve­lop­peurs se concentre ini­tia­le­ment non pas sur l’exac­ti­tude du code, mais sur le com­por­te­ment souhaité du logiciel. L’avantage, dans ce cas, c’est qu’il n’est pas né­ces­saire d’avoir une com­pré­hen­sion technique du code pour écrire des scénarios de test et qu’il est donc possible d’impliquer les parties con­cer­nées et les res­pon­sables qualité dans le processus de dé­ve­lop­pe­ment. En général, il se dit que le BDD propose la meilleure approche dans l’écriture, tandis que le TDD assure une ar­chi­tec­ture propre.

Le tableau suivant compile les avantages et les in­con­vé­nients du dé­ve­lop­pe­ment piloté par les tests :

Bien que les dif­fé­rentes méthodes de test puissent être utilisées in­di­vi­duel­le­ment, une com­bi­nai­son de méthodes de dé­ve­lop­pe­ment axées sur les tests et le com­por­te­ment aboutira à un logiciel de meilleure qualité. Cela garantit également une plus grande sa­tis­fac­tion de l’uti­li­sa­teur final.