Accueil > Blogue > Test Driven Development. (TDD)
TDD

Test Driven Development. (TDD)

Par : Publipage

Souvent, les entreprises se demandent:

— Malgré des centaines d’heures d’analyse, un design parfait, une architecture impeccable, pourquoi sommes -nous incapable de faire évoluer notre code? Pourquoi la liste de bogues s’allonge-t-elle de jour en jour?

La question que je pose toujours est :

— Avez-vous des tests?

Habituellement, la réponse (quand elle n’est pas carrément « non ») est :

— Nous en avions au début, mais on manque souvent de temps pour les faire.

Le Test Driven Developpement (TDD) est très souvent mal compris et exécuté à l’envers. Combien de fois ai-je entendu des gestionnaires dire : « N’oubliez pas de prévoir du temps pour écrire vos tests ». Malheureusement, c’est ce qui est abandonné en premier; faute de temps et parce qu’ils sont faits alors qu’il est trop tard, c’est-à-dire après. Pourtant, le principe de base du TDD c’est d’écrire les tests AVANT le code de production et non l’inverse. Écrire les tests après est pratiquement inutile, on teste alors le code en s’assurant d’en couvrir le plus possible au lieu de tester les fonctionnalités.

Les règles du TDD sont fort simples:

— Écrire un test qui échoue.

— Écrire juste assez de code de production pour faire passer le test (pas plus, pas moins).

— Nettoyer le code.

Évidemment, c’est une discipline beaucoup plus élaborée et il y a des règles pour ne pas tourner en rond ou écrire des tests inutiles, mais dans l’ensemble, ce sont les règles de base. Le maître de l’art dans cette discipline est Uncle Bob (vous pouvez visionner ses vidéos de formation sur cleancoders.com). Cette discipline  fonctionne par des petits pas, étape par étape, et permet, au final, d’écrire du code de production beaucoup plus rapidement et proprement.

Voici une liste non exhaustive des avantages :

1. Le code est plus simple et plus propre:

Comme on n’écrit que le code nécessaire pour faire passer les tests et que ce code est nettoyé au fur et à mesure, le code est toujours très propre et très léger. Aucune ligne de code n’est écrite « au cas ou », aucun « todo », aucun objet n’existe sans avoir de but précis.

2. Éloigne les chimères:

Plusieurs, disons la plupart, des développeurs/analystes/architectes/directeurs/ect. ont la maladie du « et si » :

Et si l’usager clique sur ce bouton?

Et si le format change?

Et si l’an prochain nous changeons d’idée?

Et si nous avons besoin d’une fonctionnalité de plus?

Et si?

Et si?

Et si?

C’est ce qu’on appelle les « chimères ». Avec le TDD, on ne développe que ce qui est immédiatement nécessaire. C’est s’occuper de l’avenir sans s’en préoccuper. Une technique idéale pour réduire l’angoisse du changement.

3. Moins de temps de débogage:

Le temps de débogage des développeurs diminuera drastiquement, car pour chaque bout de code, il y a un test. Pour trouver un bogue, il suffit d’écrire un test qui représente la situation désirée et faire passer ce test. Fini les heures interminables à déboguer le code.

4. L’application est déjà toute testée: (Moins de contrôle qualité nécessaire)

Avant même que l’application soit utilisée, chacune de ses fonctionnalités est testée. Cela réduit drastiquement le temps nécessaire pour le contrôle de qualité (QA).

5. S’intègre bien dans le code existant:

Même si le reste du code n’est pas testé, vous pouvez tester les nouveaux modules. J’ai souvent développé des modules 100% en TDD et à chaque fois, mon code s’imbriquait très bien dans la situation réelle et fonctionnait du premier coup. De plus maintenant, avant de modifier du code non testé, je rédige des tests du mieux que je peux avant d’effectuer la modification.

6. Les spécifications sont écrites:

Les documents d’analyses et d’architectures ne seront jamais aussi à jour que les tests. Les tests sont les spécifications du code de production, ils lui disent quoi faire, comment réagir, quels comportements avoir.  Cela permet de diminuer la documentation externe au minimum et les commentaires dans le code deviennent obsolètes et sans importance.

7. On peut perdre le code:

Comme les tests sont la spécification du code, on pourrait perdre 100% du code de production et ce ne serait pas dramatique, car on pourrait le réécrire à 100%. Bien sûr l’effort serait colossal, mais pas impossible, bien au contraire. Au final, le code serait probablement encore plus propre, plus simple et encore plus flexible que la version qui aurait été perdue. Évidemment, cette situation n’est souhaitée à personne!

8. Si les tests passent : on déploie:

Comme le code est pratiquement testé à 100%, quand les tests passent, alors vous pouvez déployer. Cela réduit au maximum les tests de régression, les semaines de QA, les inquiétudes pré/post mise en production. La règle est claire : les tests passent alors on déploie.

9. Et le plus important, les tests éliminent la peur:

Comme on vient de le voir, les tests enlèvent la peur de déployer, mais aussi ils enlèvent  la peur:

– Du changement:

Plus aucune crainte de déplacer un objet ou une ligne de code. Ça ne provoquera pas  l’écroulement du château de cartes qu’est devenu le code et les changements n’auront pas des impacts imprévus dans l’application. Si les tests passent alors tout va bien!

– Du ménage:

Le code peut être changé, nettoyé, restructuré, allégé sans crainte. Encore une fois, tant que les tests passent, il n’y a pas de problème. Aussi, c’est beaucoup plus simple d’améliorer les performances du code si les développeurs n’ont pas peur de briser les fonctionnalités déjà en place.

– De l’évolution dans  le temps :

Tant et aussi longtemps que la discipline de TDD continue, le code peut évoluer dans le temps. Comme nous l’avons vu plus haut contrairement à la documentation, les tests évoluent au fur et à mesure qu’évolue le logiciel. Peu importe si votre équipe de QA a changé ou n’existe plus ou n’a jamais existé.

– Du roulement de personnel :

Votre meilleur développeur vient de vous quitter? Le code n’a pas été ouvert depuis des lustres? Vous voulez ajouter de nouveaux employés au projet? Aucun problème! Les tests sont les spécifications et donc la connaissance n’est plus enfermée dans quelques cerveaux essentiels à la survie de votre entreprise.

Alors, pour tous vos futurs développements, sans hésitation, passez au TDD.

Et si vos applications ne sont pas testées; pas de panique, ne jetez pas tout à la poubelle. Il existe des techniques pour transformer votre projet et le rendre « testable ». Je vous suggère le livre Working Effectively with Legacy Code de Micheal Feathers.

 

Amusez-vous bien!

Partager cet article

Articles reliés

Publitrac
Haut