Test Driven Development (TDD) : comment ça marche ?

Avec la complexification constante des programmes informatiques, les méthodes agiles du Test Driven Development (TDD) sont de plus en plus privilégiées. Il y a de bonnes raisons à cela : grâce au TDD, les programmeurs s’assurent que le design d’un logiciel est bien pensé avant de commencer à écrire le code. Cette procédure augmente non seulement considérablement la qualité du logiciel, mais réduit aussi les frais de maintenance.

Le développement piloté par les tests est particulièrement utilisé dans l’extreme programming, car il se distingue par des examens, des tests, une conception et une refonte en continu. Les méthodes de Test Driven Development suivent un cycle de développement dont l’ordre doit être respecté afin de garantir son efficacité.

Il existe depuis longtemps différentes méthodes permettant de contrôler la qualité des logiciels. Au tout début du développement de logiciel déjà, des programmes informatiques de test indépendants du secteur de la gestion de qualité en vérifiaient les fonctionnalités. Le développement concret des logiciels et le test de ceux-ci étaient encore considérés comme des processus indépendants l’un de l’autre. L’approche Test-First a d’abord été développée par Kent Beck, développeur de logiciels américain et fondateur de l’Extreme Programming. Celui-ci a tout simplement inversé le processus utilisé jusque-là : au lieu de commencer par écrire le code source et de le tester ensuite, l’équipe de développeurs commence par écrire le test. Puis les scénarios de test sont utilisés pour écrire et implémenter le meilleur code possible.

Même si le développement 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 procédures conventionnelles 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éterminer les cas tests qui échouent fréquemment. Cela est fait exprès, car dans la deuxième étape, vous n’écrivez que la quantité de code nécessaire pour réussir le test. Les composants sont ensuite remaniés : tout en conservant ses fonctions, vous étendez le code source ou le restructurez si nécessaire.

Le Test Driven Development 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 production que lorsque le logiciel répond à toutes les attentes. Cela signifie que vous refaites et testez à nouveau les composants 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éveloppement incrémental dans le développement de logiciels.

Les scénarios individuels de test ne passent généralement que quelques secondes ou minutes dans le cycle. Ainsi, les résultats sont rapidement visibles dans le code de production. Pour que l’itération se fasse sans effort supplémentaire, vous avez besoin d’un outil et d’un framework TDD. Généralement, les développeurs utilisent un outil de moteur d’intégration comme CruiseControl ou Jenkins. Cela permet d’assurer l’intégration des composants en continu et sans erreurs dans le code source. JUnit, Maven ou Ant sont également populaires pour le développement 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 disponibles pour le PHP.

Mais comment se déroulent exactement ces procédures de test ? Le cycle que suivent les développeurs dans le cadre du Test Driven Development est également appelé la méthode du Red, Green, Refactor. Il s’agit des différentes phases qui doivent être respectées pour garantir une efficacité maximale :

1. Phase rouge : dans cette phase, vous vous mettez à la place de l’utilisateur. Celui-ci veut pouvoir utiliser simplement le code. Vous écrivez donc un test, qui contient des composants qui n’ont pas encore été implémentés. Vous devez décider quels éléments sont réellement indispensables pour que le code soit fonctionnel.
2. Phase verte : supposons que le test échoue et qu’il est marqué en rouge. Vous endossez maintenant le rôle du programmeur et essayez de trouver une solution simple. Attention : n’écrivez que le strict nécessaire. Vous l’intégrez dans le code de production afin que le test soit marqué en vert.
3. Refactoring : dans cette étape, le code de production est littéralement « rangé » et sa structure améliorée. Cela signifie que vous devez le compléter et le restructurer pour qu’il soit élégant et compréhensible du point de vue du développeur. Par exemple, supprimer la duplication des codes et atteindre un niveau professionnel.

Veillez à ce que les différentes activités ne se chevauchent pas. Cela signifie que vous n’écrivez pas de tests dans les phases 2 et 3, ni de code de production dans les phases 1 et 3. Dans la vidéo suivante, vous pouvez voir comment fonctionne en pratique le développement piloté par les tests :

Le Test Driven Development est une stratégie de conception, qui guide le processus de développement d’un logiciel au moyen de différents tests. Contrairement aux processus en aval, les scénarios de test de la méthode TDD sont effectués dès le début de la conception 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 composants individuels d’un programme informatique. Les tests d’intégration et fonctionnels qui permettent de vérifier l’interaction des différentes parties du système et la fonctionnalité globale d’un logiciel sont plus complexes.

Depuis quelques années le Behavior Driven Development (BDD), également appelé programmation pilotée par le comportement, se développe. Dans ce cas, l’équipe de développeurs se concentre initialement non pas sur l’exactitude du code, mais sur le comportement souhaité du logiciel. L’avantage, dans ce cas, c’est qu’il n’est pas nécessaire d’avoir une compréhension technique du code pour écrire des scénarios de test et qu’il est donc possible d’impliquer les parties concernées et les responsables qualité dans le processus de développement. En général, il se dit que le BDD propose la meilleure approche dans l’écriture, tandis que le TDD assure une architecture propre.

Le tableau suivant compile les avantages et les inconvénients du développement piloté par les tests :

Bien que les différentes méthodes de test puissent être utilisées individuellement, une combinaison de méthodes de développement axées sur les tests et le comportement aboutira à un logiciel de meilleure qualité. Cela garantit également une plus grande satisfaction de l’utilisateur final.