it-swarm-fr.com

Quels sont les inconvénients de la programmation de test - première?

C'est toute la rage de nos jours. "Tout le monde" le recommande. Que dans et d'elle-même me rend méfiant.

Quels sont certains inconvénients que vous avez trouvés lors du développement du test - premier (axé sur les tests)? Je recherche des expériences personnelles de praticiens compétents - je peux lire les références hypothétiques d'une centaine de wannabes ailleurs sur Internet.

Je ne demande pas parce que je cherche à détester TDD, mais parce que c'est mon travail d'améliorer le processus de développement de logiciels, et plus nous pouvons en apprendre davantage sur les problèmes rencontrés par les personnes rencontrées, meilleures chances d'améliorer le processus.

48
Alex Feinman

Il y en a pas mal, mais les avantages loin l'emportent sur les inconvénients.

Il y a une courbe d'apprentissage escarpée.

De nombreux développeurs semblent s'attendre à ce qu'ils puissent être efficaces avec la première programmation de test: première programmation dès le premier jour. Malheureusement, il faut beaucoup de temps pour acquérir de l'expérience et de programmer à la même vitesse qu'auparavant. Vous ne pouvez pas vous déplacer.

Pour être plus précis, il est très facile de se tromper. Vous pouvez très facilement (avec de très bonnes intentions) finir par écrire tout un tas de tests difficiles à maintenir ou à tester les mauvaises choses. Il est difficile de donner des exemples ici - ce genre de problèmes prennent simplement une expérience pour résoudre. Vous devez avoir une bonne idée de séparer les préoccupations et la conception de la testabilité. Mon meilleur conseil ici serait de faire une programmation par paire avec une personne qui connaît vraiment TDD.

Vous faites plus de codage avant.

Test - d'abord signifie que vous ne pouvez pas sauter des tests (ce qui est bon) et signifie que vous allez finir par écrire plus de code à l'avance. Cela signifie plus de temps. Encore une fois, vous ne pouvez pas vous déplacer. Vous êtes récompensé par le code qui est plus facile à maintenir, étendre et généralement moins de bugs, mais cela prend du temps.

peut être une vente difficile aux gestionnaires.

Les gestionnaires de logiciels ne concernent généralement que des délais. Si vous passez à la première programmation de test et vous prenez soudainement 2 semaines pour compléter une fonctionnalité au lieu d'un, ils ne l'aimeront pas. C'est certainement une bataille qui vaille la peine de se battre et de nombreux gestionnaires sont suffisamment éclairés pour l'obtenir, mais cela peut être une vente difficile.

peut être une vente difficile aux autres développeurs.

Comme il y a une courbe d'apprentissage escarpée, tous les développeurs comme test - première programmation. En fait, je suppose que la plupart des développeurs ne l'aiment pas au début. Vous pouvez faire des choses comme une programmation par paire pour les aider à se mettre à la hauteur, mais cela peut être une vente difficile.

En fin de compte, les avantages l'emportent sur les inconvénients, mais cela n'aide pas si vous ignorez simplement les inconvénients. Savoir ce que vous traitez dès le départ vous aide à négocier certains, sinon tous, des inconvénients.

41
Jaco Pretorius

Test - suppose d'abord que vous écrivez le code qui est:

  • testable de manière unitaire
  • que ce que vous développez a une approche évidente et ne nécessitera pas de prototypage ou d'expérimentation étendus
  • que vous n'aurez pas besoin de refroidir trop lourdement ou que vous avez le temps de réécrire à plusieurs reprises des centaines ou des milliers de cas de test
  • rien n'est scellé
  • tout est modulaire
  • tout est injectable ou moqueur
  • que votre organisation place une valeur suffisamment élevée sur les faibles défauts pour justifier le puits de ressources
  • qu'il y a quelque chose de bénéfice à tester à un niveau de test unitaire

Si votre projet ne répond pas à ces exigences, vous aurez des difficultés. Les promoteurs de TDD n'ont aucune bonne réponse à cet autre pour vous suggérer de redéfinir votre produit pour mieux tomber dans ces lignes. Il y a des situations où cela est impossible ou indésirable.

En pratique, il peut également postuler un énorme problème avec les personnes qui pensent que les tests de test - Les premiers tests prouvent réellement quoi que ce soit sur la bonne fonction du programme. Dans de nombreux cas, ce n'est pas vrai, mais même dans les cas où il est vrai, il est loin d'une image complète de l'exactitude. Les gens voient des centaines de tests de passage et supposent qu'il est prudent de tester moins depuis avant TDD, ils n'ont fait que quelques centaines de cas de test. Dans mon expérience, TDD signifie que vous devez avoir des tests encore plus d'intégration, car les développeurs auront également la fausse sécurité et la douleur de la modification de tous les tests pour faire un grand rédacteur peut conduire les développeurs à faire du travail intéressant.

Exemples:

Mon meilleur exemple personnel est lorsque vous écrivez le code de sécurité pour ASP.NET. S'ils sont destinés à courir dans un environnement hostile à partir de la configuration de la machine, ils sont gac'ed, signés et scellés, et parce qu'ils fonctionnent contre IIS objets, ils sont très difficiles à se moquer de se moquer de manière très difficile Une grande partie de correctement. Ajoutez certaines contraintes pour la performance et l'utilisation de la mémoire et vous perdez très rapidement la flexibilité pour utiliser des objets de placement dans les zones restantes.

Toute sorte de micro contrôleur ou un autre code d'environnement de ressources basse peut ne pas être possible de faire véritablement OO Conception de style lorsque les abstractions n'ophabent pas et que vous avez des limites de ressources faibles. La même chose peut être dite pour routines de haute performance dans de nombreux cas également.

36
Bill

Le plus gros inconvénient que j'ai vu n'est pas avec TDD lui-même mais avec des pratiquants. Ils prennent une approche dogmatique et zélote ( où tout doit être testé . Parfois (plusieurs fois c'est), ce n'est pas nécessaire. En outre, cela pourrait ne pas être pratique (.ie. Introduire une organisation à TDD.)

Un bon ingénieur découvre des compromis et applique le bon équilibre de quand/où/comment appliquer le test - premier. De plus, si vous vous trouvez constamment dépenser beaucoup plus de temps de développer des tests au lieu d'un code réel (par un facteur de 2-3 ou plus), vous avez des problèmes.

En d'autres termes, soyez pragmatique et raisonnable avec TDD (ou quoi que ce soit dans le développement de logiciels pour cette affaire.)

26
luis.espinal

J'ai commencé à faire TDD début août 2009 et j'ai convaincu toute ma société de passer à elle en septembre/octobre 2009. Actuellement, toute l'équipe de Dev est entièrement convertie et commettre le code non testé au repos est considéré comme une mauvaise chose et jeté. Cela nous a bien fonctionné pour nous, et je ne peux pas imaginer passer à la codage du cow-boy.

Cependant, il y a deux problèmes qui sont assez perceptibles.

la suite de test doit être maintenue

Lorsque vous êtes sérieux au sujet de TDD, vous finirez par écrire lots des tests. De plus, il faut du temps et une expérience pour réaliser ce qui est le droit Droit La granularité des tests (trop mauvaises que les sous-aliments). Ces tests sont également Code , et ils sont susceptibles au bittrot. Cela signifie que vous devez les maintenir comme tout le reste: mettez-le à jour lorsque vous mettez à niveau les bibliothèques dont ils dépendent, refacteur de temps en temps ... Lorsque vous apportez de gros changements dans votre code, beaucoup de tests deviendront soudainement obsolètes ou même mal. Si vous avez de la chance, vous pouvez simplement les supprimer, mais beaucoup de fois, vous finirez par extraire les bits utiles et les adapter à la nouvelle architecture.

Tester des abstractions Fuite de temps en temps

Nous utilisons Django, qui a un très bon cadre de test. Cependant, il fait parfois des hypothèses légèrement en contradiction avec la réalité. Par exemple, certains middleware peuvent casser les tests. Ou, certains tests font des hypothèses sur un backend de mise en cache. De plus, si vous utilisez un "réel" dB (non sqlite3), la préparation de la DB pour les tests prendra beaucoup de temps. Bien sûr, vous pouvez (et devrait) utiliser SQLITE3 et une DB en mémoire pour les tests que vous effectuez localement, mais certains code se comportent simplement différemment en fonction de la base de données que vous utilisez. Configuration d'un serveur d'intégration continu qui fonctionne dans une configuration réaliste est un must.

(Certaines personnes vous diront que vous devriez vous moquer de toutes les choses comme la base de données, ou vos tests ne sont pas "purs", mais ce n'est que l'idéologie parlant. Si vous faites des erreurs dans votre code moqueur (et croyez-moi, vous allez), votre testsuite sera sans valeur.)

Tout cela dit, les problèmes que j'ai décrits commencent à être perceptibles que lorsque vous êtes assez avancé avec TDD ... Lorsque vous commencez tout juste par TDD (ou que vous travaillez sur des projets plus petits), le refactoring, ne sera pas un problème.

6
Ryszard Szopa

Pour moi, il y a un problème psychologique profond avec des tests chaque fois que j'essaie de les appliquer de manière approfondie, comme dans TDD: s'ils sont là, je code de manière sylvolelle parce que je fais confiance à ce que les tests attireront des problèmes. Mais s'il n'y a pas de test pour fournir un filet de sécurité, je code soigneusement et le résultat est invariablement meilleur que les tests.

Peut-être que c'est juste moi. Mais j'ai également lu quelque part que les voitures avec toutes sortes de sonneries de sécurité et de sifflets ont tendance à s'écraser plus (car les conducteurs savent que les caractéristiques de sécurité sont là), alors peut-être que c'est quelque chose à reconnaître; TDD peut être incompatible avec certaines personnes.

4
Joonas Pulakka

Une situation dans laquelle le test - est vraiment vraiment dans mon chemin, c'est quand je veux essayer rapidement une idée et voir si cela peut travailler avant d'écrire une bonne implémentation.

Mon approche est normalement:

  1. Mettre en œuvre quelque chose qui fonctionne (preuve de concept).
  2. Si cela fonctionne, consolidez en ajoutant des tests, améliorant la conception, le refactoring.

Parfois, je ne reçois pas à l'étape 2.

Dans ce cas, l'utilisation de TDD s'est avérée avoir plus d'inconvénients que des avantages pour moi:

  • Les tests d'écriture lors de la mise en œuvre de la preuve du concept me ralentiront et interromptent mon flux de pensées: je veux comprendre une idée et je ne veux pas perdre de temps à tester les détails de ma première mise en œuvre approximative.
  • Cela peut prendre plus de temps pour savoir si mon idée vaut quelque chose ou non.
  • S'il s'avère que l'idée était inutile, je dois jeter mes tests de mon code et mes tests unitaires joliment écrits.

Donc, quand je dois explorer de nouvelles idées, je n'utilise pas TDD et n'introduisez que des tests unitaires lorsque je reçois un sentiment que le nouveau code se fait quelque part.

2
Giorgio

Inconvénients ou coûts de TDD

Remarque: il existe une gamme de types de TDD différents. Indépendamment de l'unité, BDD, ATDD ou d'autres variantes Beaucoup de difficultés restent

Effets secondaires

Que ce soit en moqueur, les installations ou les tests fonctionnels, les dépendances sur des états ou des systèmes externes sont souvent la source de la plupart de la complexité des tests, de la confusion dans la manière de tester et de la plus gros risque de se tromper. Quelques problèmes que j'ai vus:

  • Moqueur: oubliez d'affirmer l'ordre des appels
  • Moqueur: Mock ne correspond pas à un appel ou de réponse réel
  • Fixation: le test repose sur des données irréalistes, masquant d'autres problèmes
  • Fixation: Testez un état impossible en production
  • Fonctionnel: fausse construit des pauses en raison du système dépendant étant temporairement indisponible
  • Fonctionnel: la vitesse du test est très lente

Vous devrez changer votre approche du codage, car il s'agira d'un changement radical.

Différentes personnes codent de différentes manières différentes. Dans TDD, vous devez commencer par un test qui affirme un comportement spécifique, puis implémenter afin que le test passe. J'ai vu et un programmeur dont la programmation n'était pas propice à TDD. Cela m'a fallu environ 2 mois lorsque j'ai initialement commencé à m'habituer à changer d'approche de développement.

Il faut du temps pour comprendre ce que vous aimez les tests et ce que vous vous souciez de tester.

Chaque équipe devrait prendre une décision explicite sur l'endroit où ils veulent dessiner la ligne dans les tests. Quelles sont les choses qu'ils apprécient qu'ils veulent testé et ce qu'ils ne le font pas. C'est souvent un processus douloureux en apprenant comment écrire de bons tests et ce que vous vous souciez réellement des tests. En attendant, le code continuera d'être dans un état de flux jusqu'à ce qu'il y ait une cohérence dans le style et l'approche.

Spécifique du test unitaire: grands refacteurs

Un refacteur important ou fondamental d'une base de code importante avec des dizaines de milliers de tests unitaires générera un coût considérable afin de mettre à jour tous les tests. Cela se manifeste souvent par des retombées contre faire un refacteur, même si c'est la bonne chose à faire simplement parce que le coût associé à le faire.

1
dietbuddha

Mon analogie est des barrières sur une piste scalextrique. Si vous les mettez, vous êtes beaucoup moins prudent.

Les gens obtiennent également un peu de cadétiste de l'espace sur leurs tests - car ils courent bien, ils croient que le code est complètement testé alors que ce n'est que le début du processus de test.

À mon esprit, TDD est un tremplin vers BDD. Un radeau de tests qui fonctionnent ne permet pas de soutenir les développeurs sans savoir ce que font les tests. Avec BDD, la sortie de test est en anglais qui documente les tests et renforce ainsi la compréhension du système.

0
Robbie Dee