La pratique "TDD" ou lorsque les développements sont pilotés par les tests...

Dans le l'approche "Cycle en V", les deux étapes de développement et test sont deux choses différentes, une équipe va faire toute la réalisation nécessaire, puis elle va passer la main à l'équipe de tests pour tester ce qui a été codé, du coup on se trouve avec 2 visions différentes (Testeurs / Développeurs).

Dans le mode agile, les tests de qualification sont souvent créés à l’aide d’outils permettant d'avoir une suite d'actions à câbler sur le code réalisé pour l'exécuter et déduire les anomalies et bugs, mais c'est toujours le même problème vu que les développeurs ne travaillent pas souvent en étroite collaboration avec les testeurs. En plus il faut commencer par créer le code d'abord avant de se lancer dans la philosophie de tests.

Pourquoi pas alors commencer par élaborer et lancer les tests d'abord, et ensuite l'équipe de réalisation va essayer de couvrir et éliminer les retours identifiés avec des bouts de code à insérer au fur et à mesure.

Cette technique de développement est tout simplement ce qu'on appelle l'acronyme "TDD" (Test Driven Development), ou "Développement Piloté par les Tests", qui consiste comme expliqué dans le paragraphe précédent à bien structurer et organiser le code créé en priorisant d'abord l'écriture des tests unitaires à travers le schéma ci-dessous :

1. Écrire et construire un premier test unitaire.

2. Passer le test écrit (Automatiquement c'est KO vu qu'il n y ' a pas de code déjà écrit).

3. Couvrir le test par l'ajout d'un bout de code.

4. Re-passer le Test en question et doit normalement bien passer cette fois ci.

5. Répéter les étapes de 1 à 4 afin d'améliorer le code écrit, et réaliser en fin de compte la fonctionnalité ou l'User Story souhaitée.

Cette technique de développement présente plusieurs avantages, en occurrence :

Avoir une seule vision partagée entre le client, les testeurs, et les développeurs.

• Avoir un code propre, cohérent, bien organisé, et optimisé, permettant de faciliter la maintenance après.

• Les tests unitaires sont réellement écrits et pas remis à plus tard par les développeurs.

• Minimiser le nombre de retours et anomalies car les développeurs seront plus vigilants et concentrés sur le code créé.

• Baisser ou éliminer la "Dette technique'" par le biais du remaniement du code appliqué avec cette technique.

• Produire des incréments produits, et un produit final de grande qualité significative permettant de gagner la confiance et la satisfaction du client final.

Conclusion :

La pratique TDD reste parmi les meilleures pratiques du référentiel Agile, ainsi qu'une méthode de design du code. Elle vous permettra de bien organiser vos tests unitaires, d'écrire que les tests nécessaire à l'avance en collaboration avec les développeurs, et d'avoir un code propre facile à maintenir permettant d'éviter la Dette technique dans le futur.

Il existe plusieurs outils permettant de gérer la pratique TDD, et c'est à chaque équipe de voir quel est l'outil adéquat pour elle. Et l'essentiel reste toujours d'avoir une seule vision partagée permettant de produire des logiciels et applications de qualité.