Test Driven Development pour des applications web de qualité

L’une des étapes les plus essentielles de tout projet de développement d’application web est l’étape de test. Si ce processus est ignoré, les résultats peuvent être désastreux, à la fois pour le projet et pour l’entreprise. Mais quand un projet doit-il être testé ? Il semble logique de tester le projet lorsqu’il est terminé. Cependant, la puissance de la procédure de test classique est limitée. La sur-ingénierie, la conception rigide, les problèmes de testabilité, ne sont que quelques problèmes que vous pourriez rencontrer si vous écrivez d’abord le code et testez l’implémentation plus tard. Au même titre qu’une méthodologie Scrum sur la partie développement, il existe un moyen de tester votre produit tout au long du projet grâce au Test Driven Development. Cet article vous fournit une introduction au TDD et explique comment le processus peut rendre l’écriture des tests beaucoup plus simple.

Qu'est-ce que le Test Driven Development ?

‍

L'origine du Test Driven Development (TDD)

Les tests sont l'une des parties les plus cruciales de tout projet de développement. Effectivement, lorsque vous créez une suite de tests robuste et complète, vous pouvez détecter les bugs, les erreurs et les hypothèses incorrectes que vous avez formulées dans l'écriture de votre code. En utilisant de nombreux types de tests, vous serez plus susceptible de lancer un produit final de meilleure qualité.

La triste réalité est que les tests sont trop souvent une réflexion après coup, ou ils sont simplement traités comme une case à cocher. Les équipes de développement qui peinent à respecter la pression des délais et des contraintes budgétaires n’ont pas le temps de se consacrer aux tests que le développement mérite pleinement.

‍

Dans les années 1990, Kent Beck a découvert une idée dans un vieux manuel d'informatique. Lors de la création d'une fonction, définissez d'abord quelques exemples de résultats attendus pour une entrée spécifique donnée. Une fois, la fonction créée, comparez la fonction aux résultats attendus.

‍

Il savait que l'idée était si bonne, qu'il a décidé de créer un cadre pour vérifier automatiquement les résultats et pour revérifier à chaque nouvelle fonction. C'est à ce moment que le Test Driven Development TDD est né. D'ailleurs, le TDD est également appelé Test First Development. Un grand changement par rapport aux méthodes plus traditionnelles. Ce n'est pas seulement un changement dans la façon dont les gens travaillent, mais un état d'esprit complètement différent.

‍

La définition du Test Driven Development

Le Test Driven Development (en français le développement piloté par des tests), est une méthode de développement qui consiste à écrire une série de tests avant d’écrire le code. Peu importe si nous parlons de développement piloté par les tests en Python ou en Java. Dans la pratique, le TDD vise toujours à écrire du code propre qui fonctionne.

‍

Pour comprendre la définition des développements pilotés par les tests, nous devons d'abord définir les tests unitaires, qui sont un concept essentiel dans TDD. Le test unitaire est une méthode de test qui décompose une application en petites parties appelées unités. Chaque unité est évaluée individuellement et indépendamment par une série complète de tests écrits spécifiquement pour cette unité. Afin d'aider au débug, les tests unitaires doivent être aussi courts et simples que possible, afin que les développeurs puissent découvrir plus facilement l'erreur.

‍

Par exemple, supposons que nous écrivons du code pour une application de calculatrice et que nous souhaitons tester le programme à l'aide de tests unitaires. Nous pourrions écrire un test unitaire pour chacune des fonctions de la calculatrice : addition, soustraction, multiplication, division, exponentielles, etc. Nous aurions également besoin de tests unitaires pour des activités telles que l'effacement de l'écran de la calculatrice et la composition de plusieurs opérations.

‍

Le but des tests unitaires est de trouver les bugs et les problèmes au début du cycle de vie du développement. Une suite de tests unitaires pour une grande application peut avoir des centaines ou des milliers de tests unitaires, dont chacun doit passer pour que le développement se poursuive.

‍

Les principes du Test Driven Development

Le Test Driven Development consiste à écrire d'une application web (ou logiciel) en faisant des tests unitaires la préoccupation la plus importante. Le TDD est une approche hautement structurée et réglementée de développement. Cette pratique possède plusieurs principes :

• Les tests sont toujours écrits avant le code qui les fera passer. Le test anticipe le comportement correct du code.
• Le développement procède à un test à la fois. Une fois qu'un test passe de l'échec à la réussite, le test suivant est écrit et le processus développement peut se poursuivre.
• Encore une fois, les tests doivent être aussi simples que possible, juste assez longtemps pour interrompre l'application dans son état actuel. Une fois le test rédigé, tout le développement doit se concentrer sur la réussite du logiciel.

‍

D'ailleurs, nous pouvons considérer le TDD comme une stratégie de conception. Effectivement, comme le test, est écrit en premier, l'interface du composant à tester est déjà utilisée avant d'exister réellement. Par conséquent, les développeurs reçoivent des retours sur la viabilité de leur code dès la phase de conception.

‍

Le TDD se déroule dans des cycles qui sont généralement appelés Rouge - Vert - Refactor. Ce cycle est généralement effectué une fois pour chaque test unitaire que vous écrivez.

Le cycle se compose de trois étapes :

• Test Fail : écrivez un test unitaire qui échoue en raison d'une fonctionnalité manquante dans le logiciel (car la couleur rouge indique généralement un échec).
• Test Pass :  écrivez du code qui résout le problème en faisant passer le test par le logiciel (car la couleur verte indique généralement le succès).
• Refactor : nettoyez la base de code pour tenir compte de la présence de ce nouveau code.

‍

Le TDD est comparable au processus d'écriture d'un long essai. Vous commencez à rédiger l'essai en créant un aperçu détaillé des sujets que vous souhaitez couvrir. Ensuite, vous écrivez l'une des sections de l'essai en fonction du plan et vous apportez les ajustements nécessaires au reste de l'essai en fonction du nouveau texte que vous venez d'écrire. En ayant la structure en tête à l'avance, il devient beaucoup plus facile de créer le produit final.

‍

Comment le Test Driven Development peut améliorer vos applications web ?

‍

Les 3 avantages du TDD

‍

1. Vitesse

Pour les développeurs et testeurs qualifiés qui peuvent évoluer rapidement, l'un des principaux avantages du TDD est la rapidité. En ajoutant des tests qui échouent, puis en corrigeant le code pour les faire réussir, TDD encourage une itération et une progression rapides.

Le TDD peut sembler être l'option la plus lente au début, mais l'effort initial que vous déployez sera rentable plus tard. Peu de choses sont plus désastreuses pour un projet de développement que de découvrir que la logique de votre application contient une faille majeure qui oblige le code à être re-factorisé ou réécrit (c'est terrible).

‍

En prenant le temps d'investir dès le début dans la qualité de la base de code, TDD peut faire gagner du temps et des efforts aux développeurs et réduire le risque d'échec ou de retard d'un projet.

‍

2. Automatisation plus facile

Un autre avantage lié en termes de vitesse est que le TDD et les tests unitaires facilitent considérablement l'automatisation de votre suite de tests. Les contrôles manuels sont souvent extrêmement lents, surtout si vous effectuez des tests fonctionnels qui vous obligent à suivre une série d'étapes. Le processus de test fonctionnel peut prendre quelques secondes ou minutes et doit être effectué chaque fois que vous apportez une modification au système.

‍

Les tests unitaires, en revanche, sont rapides et extrêmement faciles à automatiser. Alors que les tests manuels et automatisés ont leur place dans un programme de test mature et robuste, les tests automatisés peuvent accélérer considérablement le processus. Cela vous permet d'exécuter plus de tests dans le même laps de temps, améliorant ainsi la qualité du code.

‍

3. Code de meilleure qualité

Si vous attendez de tester votre code plus tard dans le cycle de développement, c'est une recette potentielle pour un désastre. Écrire des centaines ou des milliers de lignes de code sans faire d'erreur ni de faute de frappe est hautement improbable.

‍

En tant qu'êtres humains, même les meilleurs développeurs sont sujets à des erreurs de temps en temps, et ce n'est qu'une question de temps avant qu'une erreur ne se produise. Sans tester le code à intervalles réguliers, des bugs et des comportements inattendus sont plus susceptibles d'être introduits.

‍

Le TDD est avant tout une approche incrémentale du développement. Dans la plupart des cas, les développeurs n'écriront que quelques lignes de code à la fois, juste assez pour que le test réussisse. Cette philosophie « lente mais régulière » rassure (mais pas une garantie) que votre application ne contient pas d'erreurs.

‍

Un avantage supplémentaire de TDD est que le code lui-même peut servir de documentation. Par exemple, si vous souhaitez montrer comment une fonction se comporte si une entrée exceptionnelle (telle qu'une chaîne vide ou un nombre négatif) est donnée, il vous suffit d'écrire un test qui utilise cette entrée.

‍

Test Driven Development vs développement traditionnel

TDD peut sembler une excellente idée, mais cela n'a pas toujours été une pratique courante dans le développement d'application web (et n'est pas toujours utilisé, même aujourd'hui).

‍

Selon le modèle de développement d'application traditionnel, les projets doivent se dérouler selon une série d'étapes consécutives et séquentielles : collecte des exigences, analyse, conception, codage, test et déploiement. Ce concept est souvent appelé le modèle en « cascade », comme une cascade en cascade sur une série de roches à différents niveaux.

‍

En fait, la métaphore de la cascade est très précise. L'eau qui tombe dans une cascade coule continuellement vers le bas, sans possibilité de revenir à un niveau supérieur. De même, le modèle en cascade du développement décourage généralement le retour à un stade antérieur de développement. Tout le codage et la mise en œuvre doivent être terminés avant que les tests puissent commencer.

‍

Voir les failles avec la méthodologie de la cascade n'est pas difficile. Si de nouvelles exigences émergent à mi-chemin du projet ou si vous découvrez une faille critique dans vos hypothèses, vous n'aurez peut-être d'autre choix que de tout recommencer. En conséquence, les applications développés avec le modèle en cascade peuvent être sujets à des retards et des dépassements de budget.

Plutôt que la méthodologie traditionnelle en cascade, TDD s'intègre bien avec les méthodologies agiles qui sont actuellement en vogue auprès des développeurs. Agile privilégie la flexibilité, l'adaptabilité et la satisfaction client par rapport à des règles et réglementations strictes. En particulier, Agile utilise le développement itératif, dans lequel le logiciel est constamment publié dans son dernier état déployable afin d'obtenir des commentaires précieux des clients.

‍

La méthodologie Lean, quant à elle, trouve son origine dans des concepts issus de la construction automobile. Lean utilise l'idée du développement « Just In Time » (JIT), dans lequel les composants d'un système sont créés ou commandés juste à temps pour être utilisés dans le produit final. Le Just In Time réduit le besoin de maintenir un inventaire excédentaire et garantit que les employés travaillent toujours pour ajouter de la valeur au produit.

‍

Il n'est pas difficile de voir comment TDD et les méthodologies agiles partagent des philosophies similaires sur le développement d'application. Avec TDD, le code et les tests sont écrits de manière incrémentielle, en utilisant le minimum d'effort requis pour obtenir des commentaires et démarrer une nouvelle itération. 

‍

Les points fort du Test Driven Development

Qualité - L'une des principales raisons d'écrire des tests est d'augmenter la qualité du développment logiciel que vous écrivez. TDD vous fait réfléchir à la façon dont le code peut être utilisé et comment il devrait se comporter dans différents scénarios basés sur différentes entrées, ce qui devrait conduire à un nombre inférieur de bogues dans le code.

‍

Aide à documenter le code - Les tests peuvent être un excellent moyen de documenter une intention derrière le code et aideront les nouveaux développeurs à intégrer le code beaucoup plus rapidement et leur permettront de le modifier en toute confiance.

‍

Aide à produire un code plus propre - Comme les tests ne sont pas une réflexion après coup, mais plutôt un citoyen de première classe, il devient plus difficile de sur-concevoir une solution et de mélanger les préoccupations. Tout cela est dû à la simplicité des règles et à la concentration.

‍

Permet le refactoring - Lorsque vous avez des tests en place, ils vous donnent confiance pour modifier les détails d'implémentation en toute sécurité, sachant que les tests vous diront quand vous êtes sur le point de casser quelque chose.