Avantages et inconvénients du développement piloté par les tests

Quels sont les avantages et les inconvénients du développement piloté par les tests (TDD)?

Test Driven Development est une méthodologie de développement logiciel dans laquelle vous écrivez et Cours un ensemble de tests avant d'écrire du code.

L'idée est que ces tests échoueront au début, puis vous commencerez à écrire suffisamment de code pour essayer de faire passer tous les tests. La réussite de tous les tests peut être une mesure des critères effectués (dev-done) et augmente également la confiance dans la qualité du code.


Cela dit, comme toute autre méthodologie de développement, il existe des avantages et des inconvénients associés au TDD. Ici, nous en énumérons quelques-uns, mais avant cela, mieux vaut clarifier quelques points:

  • Faire des tests unitaires ne veut pas dire faire du TDD. Vous pouvez faire le premier sans le second. En fait, vous pouvez faire du TDD sans tests unitaires (mais la plupart des gens le font), dans ce cas, les gens complètent généralement les tests unitaires avec d'autres types de tests. Ce dont vous avez certainement besoin, ce sont des tests automatiques, quels qu'ils soient.
  • Vous pouvez effectuer TDD pour le test de la boîte blanche, pour tester votre code. Mais vous pouvez également effectuer un TDD pour les tests de boîte noire, ce que l'on appelle souvent le développement piloté par le comportement.

Traditionnellement, le processus consistait à coder de nombreux modules, puis à écrire des tests unitaires pour vérifier le code. C'est la méthode du code d'abord, testez plus tard. Mais si, après le codage, vous n'avez pas le temps ou si vous êtes poussé à la libération, alors tout l'exercice de test unitaire est ignoré, ou au mieux fait rétrospectivement.


Passons maintenant aux avantages et aux inconvénients du TDD:



Avantages du développement piloté par les tests

  • Parce que vous écrivez de petits tests à la fois, cela oblige votre code à être plus modulaire (sinon, ils seraient difficiles à tester). TDD vous aide à apprendre, comprendre et internaliser les principes clés d'une bonne conception modulaire.
  • TDD force également une bonne architecture. Afin de rendre votre code testable à l'unité, il doit être correctement modularisé. En écrivant les tests en premier, divers problèmes architecturaux ont tendance à apparaître plus tôt.
  • Documente mieux votre code que la documentation (il n'est pas obsolète puisque vous l'exécutez tout le temps).
  • Rend le code plus facile à maintenir et à refactoriser. TDD aide à clarifier le processus de mise en œuvre et fournit un filet de sécurité lorsque vous souhaitez refactoriser le code que vous venez d’écrire.
  • Rend la collaboration plus facile et plus efficace, les membres de l'équipe peuvent modifier le code les uns des autres en toute confiance, car les tests les informeront si les modifications font que le code se comporte de manière inattendue.
  • Étant donné que TDD vous oblige essentiellement à écrire des tests unitaires avant d'écrire le code d'implémentation, la refactorisation du code devient plus facile et plus rapide. Le code de refactoring écrit il y a deux ans est difficile . Si ce code est sauvegardé par un ensemble de bons tests unitaires, le processus est tellement plus facile.
  • Aide à prévenir les défauts - eh bien, au moins, cela vous aide à trouver les problèmes de conception ou d'exigence dès le début. TDD fournit une alerte précoce aux problèmes de conception (lorsqu'ils sont plus faciles à résoudre).
  • Aide les programmeurs à vraiment comprendre leur code.
  • Crée une suite de tests de régression automatisée, essentiellement gratuite. c'est-à-dire que vous n'avez pas besoin de passer du temps à écrire des tests unitaires pour tester le code d'implémentation.
  • Il encourage les petites étapes et améliore la conception car il vous permet de supprimer les dépendances inutiles pour faciliter la configuration.
  • Cela aide à clarifier les exigences car vous devez déterminer concrètement quels intrants vous devez alimenter et quels extrants vous attendez.
  • Les tests unitaires sont particulièrement utiles comme filet de sécurité lorsque le code doit être modifié pour ajouter de nouvelles fonctionnalités ou corriger un bogue existant. Étant donné que la maintenance représente entre 60 et 90% du cycle de vie du logiciel, il est difficile de surestimer comment le temps nécessaire au départ pour créer un ensemble décent de tests unitaires peut être amorti encore et encore pendant la durée de vie du projet.
  • Tester pendant l'écriture vous oblige également à essayer de rendre vos interfaces suffisamment propres pour être testées. Il est parfois difficile de voir l'avantage de cela jusqu'à ce que vous travailliez sur un corps de code là où cela n'a pas été fait, et la seule façon de s'exercer et de se concentrer sur un morceau de code donné est d'exécuter l'ensemble du système et de définir un point d'arrêt .
  • Les erreurs «stupides» sont détectées presque immédiatement. Il aide les développeurs à trouver des erreurs qui feraient perdre du temps à tout le monde si elles étaient détectées lors du contrôle qualité.


Inconvénients du développement piloté par les tests

  • La suite de tests elle-même doit être maintenue; les tests peuvent ne pas être complètement déterministes (c'est-à-dire dépendre de dépendances externes).
  • Les tests peuvent être difficiles à écrire, en particulier. au-delà du niveau de test unitaire.
  • Au départ, cela ralentit le développement; pour les environnements de démarrage rapidement itératifs, le code d'implémentation peut ne pas être prêt pendant un certain temps en raison du temps passé à écrire les tests en premier. (Mais à long terme, cela accélère en fait le développement)
  • Comme toute programmation, il y a une grande différence entre le faire et le faire bien. Ecrire de bons tests unitaires est une forme d'art. Cet aspect du TDD n'est souvent pas discuté, de nombreux gestionnaires ont tendance à se concentrer sur des mesures comme la couverture du code; ces métriques ne vous disent rien sur la qualité des tests unitaires.
  • Les tests unitaires sont une chose à laquelle toute l'équipe doit adhérer.
  • Un défi à apprendre. Cela peut être intimidant et difficile à apprendre pour quiconque au début, surtout en essayant de l'apprendre par vous-même. Cela demande beaucoup de dévouement (discipline, pratique, persévérance) et vous devez avoir le but que vous voulez toujours vous améliorer.
  • Difficile à appliquer au code hérité existant.
  • De nombreuses idées fausses empêchent les programmeurs de l'apprendre.
  • Difficile de commencer à travailler de cette façon. Surtout si vous avez de nombreuses années à travailler dans l'autre sens.
  • Il faut parfois se moquer de beaucoup de choses ou de choses difficiles à se moquer. C’est bénéfique à long terme, mais douloureux en ce moment.
  • Vous devez effectuer le ménage en permanence. Étant donné que la réservation de plus en plus de tests rend votre build de plus en plus longue, il est nécessaire d’affiner ces tests pour qu’ils s’exécutent plus rapidement ou pour supprimer les tests redondants.
  • Comme toute bonne technique, les tests unitaires peuvent être poussés à l'extrême. Les plus grands avantages proviennent d'un effort modéré, les tests exécutant toujours le code de la manière la plus simple possible. Si vous vous trouvez fréquemment à refactoriser vos tests, il y a de fortes chances que vous passiez trop de temps sur la suite de tests.
  • Il peut être facile de se laisser distraire par des fonctionnalités «fluff» ou sophistiquées dans le cadre de test unitaire. Nous devons nous rappeler que les tests simples sont les plus rapides à créer et les plus faciles à gérer.
  • Bien que cela soit absolument nécessaire, créer des tests pour les échecs peut être fastidieux, mais cela s'avère payant à la fin.
  • La refactorisation à un stade précoce nécessite également la refactorisation des classes de test.
  • À moins que tous les membres de l'équipe ne maintiennent correctement leurs tests, l'ensemble du système peut rapidement se dégrader.