Pourquoi devrais-je utiliser le développement piloté par les tests? [dupliquer]

StackOverflow https://stackoverflow.com/questions/804569

  •  03-07-2019
  •  | 
  •  

Question

Dupliquer:

Pour un développeur qui ne connaît pas le développement piloté par les tests, quel (s) problème (s) sera résolu en adoptant TDD?

[EDIT] Supposons que le développeur utilise déjà un environnement de test unitaire.

Était-ce utile?

La solution

Voici trois raisons pour lesquelles TDD pourrait aider un développeur / une équipe:

  • Une meilleure compréhension de ce que vous allez écrire
  • Applique la politique d'écriture des tests un peu mieux
  • accélère le développement

Une première raison pour écrire les tests est de mieux comprendre le code réel avant de l'écrire. Pour moi, c'est le principal avantage du développement piloté par les tests. Lorsque vous écrivez les scénarios de test pour la première fois, vous réfléchissez de manière plus critique aux cas critiques. Il est alors plus facile de les aborder lorsque vous écrivez le code et assurez-vous qu'il est exact.

Une autre raison est de forcer l’écriture des tests. Souvent, lorsque les utilisateurs effectuent des tests unitaires sans TDD, ils disposent d'un cadre de test, écrivent un nouveau code, puis cessent de fumer. Ils pensent que le code fonctionne déjà très bien, alors pourquoi écrire des tests? C'est assez simple pour que ça ne casse pas, non? Mais maintenant, vous avez perdu l'avantage de faire des tests unitaires (discussion complètement différente). Écrivez-les d'abord, et ils sont déjà là.

Si vous écrivez ces tests en premier, vous n'aurez pas besoin de lancer le programme dans un environnement de débogage (lent, en particulier pour les projets de grande taille) pour vérifier si quelques petites tâches fonctionnent. Bien sûr, il n’ya aucune excuse pour ne pas le faire avant d’engager des changements.

Il peut être difficile de convaincre vous-même ou d’autres personnes d’écrire les tests en premier. Vous aurez peut-être plus de chance en leur demandant d'écrire les deux en même temps, ce qui pourrait être tout aussi bénéfique.

Autres conseils

Vous testez probablement le code que vous avez écrit avant de le valider dans un référentiel.

Si ce n'est pas vrai, vous avez d'autres problèmes à résoudre.

Si c’est vrai, vous pouvez envisager d’écrire des tests à l’aide d’un framework afin d’automatiser les routines principales ou les pilotes que vous écrivez actuellement afin de pouvoir les exécuter automatiquement en appuyant simplement sur un bouton. Il n'est pas nécessaire d'examiner la sortie pour décider si le test a réussi ou échoué. vous intégrez le succès ou l'échec du test dans le code et obtenez immédiatement une décision favorable. Effectuer tous les tests en même temps réduit les risques de "cogner une taupe". situation où vous corrigez quelque chose dans une classe et casser quelque chose d’autre. Tous les tests doivent réussir.

Ça sonne bien jusqu'à présent, oui?

Les gens de TDD vont juste un peu plus loin en vous demandant d’écrire le test EN PREMIER avant d’écrire la classe. Cela échoue, bien sûr, parce que vous n'avez pas écrit la classe. C’est leur façon de garantir que vous écrivez des classes de tests.

Si vous utilisez déjà un framework de test, tirez le meilleur parti des tests que vous écrivez et que vous avez une couverture de code significative atteignant environ 70%, alors je pense que vous vous en sortez bien. Je ne suis pas sûr que TDD vous donnera beaucoup plus de valeur. C'est à vous de décider si vous faites ou non ce petit effort supplémentaire. Personnellement, je ne le fais pas. J'écris des tests après le cours et me refactorise si j'en ressens le besoin. Certaines personnes trouveront peut-être utile d’écrire le test d’abord en sachant qu’il échouera, mais ce n’est pas mon cas.

(Il s’agit plus d’un commentaire en accord avec la réponse de duffymo que d’une réponse en soi.)

duffymo répond:

  

Les gens de TDD vont juste un peu plus loin en vous demandant d’écrire le test EN PREMIER avant d’écrire la classe. Cela échoue, bien sûr, parce que vous n'avez pas écrit la classe. C’est leur façon de garantir que vous écrivez des classes de tests.

Je pense qu’il s’agit en réalité d’obliger les codeurs à réfléchir à ce que leur code fait. Le fait de penser à un test fait réfléchir à ce que le code est censé faire: quelles sont les conditions préalables et postérieures, quelles fonctions sont primitives et lesquelles sont composées de fonctions primitives, quelle est l'interface publique minimale nécessaire et un détail de mise en œuvre.

Ce sont toutes les choses auxquelles je pense régulièrement. Par conséquent, comme vous, testez d'abord " n’ajoute pas beaucoup, pour moi . Et franchement (je sais que c’est une hérésie dans certains milieux), j’aime "ancrer" les idées fondamentales d’une classe en esquissant d’abord l’interface publique; De cette façon, je peux le regarder, l'utiliser mentalement et voir s'il est aussi propre que je le pensais. (Une classe ou une bibliothèque doit être facile et intuitive à utiliser pour les programmeurs clients.)

En d’autres termes, je fais ce que TDD essaie de faire en vérifiant d’abord les tests, mais comme le duffymo, j’y parviens différemment.

Et le vrai point de "tester d'abord" est de demander à un codeur de faire une pause et de penser comme un designer. C'est idiot de faire un fétiche de la façon dont le programmeur entre dans cet état; pour ceux qui ne le font pas naturellement, "testez d'abord" sert de rituel pour les y amener. Pour ceux qui le font, "testez d'abord" n'ajoute pas grand chose - et cela peut entraver la manière habituelle pour le programmeur d'entrer dans cet état.

Encore une fois, nous voulons examiner les résultats, pas les rituels. Si un jeune homme a besoin d’un rituel, un "relais de la croix" ou un chapelet * pour "entrer dans le sillon", "tester en premier" sert à cette fin. Si quelqu'un a sa propre façon de s'y rendre, c'est très bien aussi.

Notez que je ne dis pas que le code ne devrait pas être testé. Cela devrait. Cela nous donne un filet de sécurité, ce qui nous permet à notre tour de concentrer notre attention sur l'écriture d'un bon code, même audacieux , car nous savons qu'il est là pour détecter les erreurs.

Tout ce que je dis, c'est que l'insistance fétichiste de "tester d'abord" confond la méthode (une parmi de nombreuses) avec l'objectif , ce qui amène le programmeur à réfléchir à ce qu'il code.

* Pour être œcuménique, je noterai que les catholiques et les musulmans utilisent des chapelets. Et encore une fois, c’est un moyen mécanique , une mémoire musculaire de se mettre dans un certain état d’esprit. C'est un fétiche (au sens original d'objet magique, pas le sens du mot "fétiche sexuel") ou un porte-bonheur. Donc, on dit "Om mani padme hum", ou zazen assis ou en caressant un "chanceux". pied de lapin, (pas si chanceux pour le lapin.) Le philosophe Jerry Fodor, lorsqu'il pense à des problèmes difficiles, a un rituel similaire: il se répète: "Allez, Jerry, tu peux le faire!" (J'ai essayé ça aussi, mais comme je ne m'appelle pas Jerry, ça n'a pas fonctionné pour moi.;))

Idéalement:

Vous ne perdrez pas de temps à écrire des fonctionnalités inutiles. Vous disposerez d'une suite complète de tests unitaires qui servira de filet de sécurité pour la refactorisation. Vous aurez des exemples exécutables de la manière dont votre code doit être utilisé. Votre flux de développement sera plus fluide et plus rapide; vous passerez moins de temps dans le débogueur.

Mais surtout, votre design sera meilleur. Votre code sera mieux factorisé - faiblement couplé, hautement cohésif - et mieux formé - des méthodes plus petites et mieux nommées & amp; classes.

Pour mon projet actuel (qui s’appuie sur un processus relativement lourd), j’ai adopté une forme particulière de TDD consistant à écrire des scénarios de test squelette basés sur des documents de besoins et des maquettes d’interface graphique. J'en écris des dizaines, parfois des centaines, avant de commencer à implémenter quoi que ce soit (cela va totalement à l'encontre du "pur" TDD qui dit que vous devriez écrire quelques tests, puis commencer immédiatement avec une implémentation squelette).

J'ai trouvé que c'était un excellent moyen de revoir les documents relatifs aux exigences. Je dois réfléchir beaucoup plus intensément au comportement qui y est décrit que si je devais les lire. En conséquence, j'y trouve beaucoup plus d'incohérences et de lacunes que je n'aurais autrement trouvées que lors de la mise en œuvre. De cette façon, je peux demander une clarification plus tôt et avoir de meilleures exigences lorsque je commence à mettre en œuvre.

Ensuite, lors de la mise en œuvre, les tests permettent de mesurer le chemin qu'il me reste à parcourir. Et ils ne m'empêchent pas d'oublier quoi que ce soit (ne riez pas, c'est un réel problème lorsque vous travaillez sur des cas d'utilisation plus importants).

Et la morale est la suivante: même si votre processus de développement ne supporte pas vraiment TDD, cela peut toujours être fait d'une manière et améliorer la qualité et la productivité.

Personnellement, je n’utilise pas la technologie TDD, mais l’un des plus gros avantages dont je dispose en ce qui concerne la méthodologie est que la satisfaction du client est assurée. En gros, l’idée est que les étapes de votre processus de développement sont les suivantes:

1) Discutez avec le client de ce que l'application est censée faire et de la manière dont elle est censée réagir à différentes situations.

2) Traduisez le résultat de 1) en tests unitaires, qui testent chacun une fonctionnalité ou un scénario.

3) Écrivez simple, " sloppy " code qui passe (à peine) les tests. Ceci fait, vous avez répondu aux attentes de vos clients.

4) Modifiez le code que vous avez écrit en 3) jusqu'à ce que vous pensiez l'avoir fait de la manière la plus efficace possible.

Lorsque cela est fait, vous avez espéré produire un code de haute qualité, qui répond aux besoins de vos clients. Si le client souhaite maintenant une nouvelle fonctionnalité, vous recommencez le cycle - discutez-en, écrivez un test pour vous assurer qu'il fonctionne, écrivez le code qui réussit le test, refactor.

Et comme d’autres l’ont dit, chaque fois que vous exécutez vos tests, vous vous assurez que l’ancien code fonctionne toujours et que vous pouvez ajouter de nouvelles fonctionnalités sans modifier l’ancien.

La plupart des personnes à qui j'ai parlé n'utilisent pas un modèle TDD complet. Ils trouvent généralement le meilleur modèle de test qui leur convient. Trouvez le vôtre et jouez avec TDD et trouvez où vous êtes le plus productif.

J'ai fait de gros efforts pour apprendre le TDD au développement de Ruby on Rails. Il a fallu plusieurs jours avant que je me suis vraiment lancé. J'étais très sceptique, mais j'ai fait l'effort parce que les programmeurs que je respecte respectent le soutenir.

À ce stade, j'estime que l'effort en valait vraiment la peine. Il y a plusieurs avantages que je suis sûr que d'autres se feront un plaisir de vous énumérer. Pour moi, le principal avantage est que cela aide à éviter cette situation de cauchemar tard dans un projet où quelque chose se brise soudainement sans raison apparente et que vous passez ensuite un jour et demi avec le débogueur. Cela évite que votre base de code ne se détériore à mesure que vous ajoutez de plus en plus de logique à celle-ci.

TDD (Test Driven Development / Design) présente les avantages suivants

  • vous garantit de connaître les critères d'acceptation de la carte récit avant de commencer
  • veille à ce que vous sachiez quand arrêter de coder (c’est-à-dire que lorsque les critères d’acceptation ont été remplis, cela empêche la création de disques dorés)

Par conséquent, vous vous retrouvez avec un code qui est

  1. testable
  2. design épuré
  3. pouvoir être refactorisé en toute confiance
  4. le code minimal nécessaire pour satisfaire la carte d'histoire
  5. spécification vivante du fonctionnement du code
  6. capable de supporter un rythme durable de nouvelles fonctionnalités

Il est de notoriété publique qu'écrire des tests et disposer d'un grand nombre de tests automatisés est une bonne chose.

Cependant, sans TDD, cela devient souvent fastidieux. Les gens écrivent des tests, puis les laissent, et les tests ne sont pas mis à jour comme ils le devraient, pas plus que les nouvelles fonctionnalités ne sont testées aussi souvent qu'ils le devraient.

Cela tient en grande partie au fait que le code est devenu difficile à tester - TDD influera sur votre conception, de sorte qu'il sera beaucoup plus facile à tester. Parce que vous avez utilisé TDD, vous disposez d’un grand nombre de tests, ce qui facilite beaucoup la recherche de régressions lorsque votre code ou vos exigences changent, simplifiant considérablement le débogage, entraînant une appréciation du bon TDD et encourageant l’écriture de nouveaux tests lorsque des modifications sont apportées. nécessaire - et nous sommes de retour au début du cycle.

Les avantages sont nombreux:

  • Qualité du code supérieure
  • Moins de bugs
  • Moins de temps perdu

N'importe lequel de ces éléments suffirait à justifier l'application du TDD.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top