Question Les tests unitaires en valent-ils la peine? [fermé]


Je travaille pour intégrer les tests unitaires dans le processus de développement de l'équipe sur laquelle je travaille et il y a des sceptiques. Quels sont les bons moyens de convaincre les développeurs sceptiques de l'équipe de la valeur de Unit Testing? Dans mon cas particulier, nous ajouterions des tests unitaires à mesure que nous ajouterions des fonctionnalités ou des bogues corrigés. Malheureusement, notre base de code ne se prête pas à des tests faciles.


573


origine


Réponses:


Chaque jour dans notre bureau, il y a un échange qui ressemble à ceci:

"J'adore les tests unitaires, je viens juste de faire un tas de changements sur la façon dont quelque chose fonctionne, et puis j'ai pu confirmer que je n'avais rien cassé en recommençant le test ..."

Les détails changent tous les jours, mais pas le sentiment. Les tests unitaires et le développement piloté par les tests (TDD) ont tellement d'avantages cachés et personnels, mais aussi des avantages évidents que vous ne pouvez pas vraiment expliquer à quelqu'un avant de le faire lui-même.

Mais, ignorant cela, voici ma tentative!

  1. Les tests unitaires vous permettent de faire de gros changements au code rapidement. Vous savez que cela fonctionne maintenant parce que vous avez exécuté les tests, lorsque vous effectuez les modifications nécessaires, vous devez faire en sorte que les tests fonctionnent à nouveau. Cela économise des heures.

  2. TDD vous aide à réaliser quand arrêter le codage. Vos tests vous donnent l'assurance que vous en avez assez fait pour l'instant et peuvent arrêter de peaufiner et passer à la prochaine étape.

  3. Les tests et le code fonctionnent ensemble pour obtenir un meilleur code. Votre code pourrait être mauvais / bogué. Votre TEST pourrait être mauvais / bogué. Dans TDD, vous mentez sur les chances de tous les deux être mauvais / buggy étant faible. Souvent, c'est le test qui a besoin d'être réparé, mais c'est toujours un bon résultat.

  4. TDD aide à coder la constipation. Lorsque vous êtes confronté à un travail important et impressionnant avant d'écrire les tests, vous allez vous déplacer rapidement.

  5. Les tests unitaires vous aident à comprendre la conception du code sur lequel vous travaillez. Au lieu d'écrire du code pour faire quelque chose, vous commencez par décrire toutes les conditions auxquelles vous soumettez le code et les sorties que vous attendez de cela.

  6. Les tests unitaires vous donnent un retour visuel instantané, nous aimons tous le sentiment de tous ces feux verts quand nous l'avons fait. C'est très satisfaisant. Il est également beaucoup plus facile de reprendre là où vous vous étiez arrêté après une interruption parce que vous pouvez voir où vous êtes arrivé - la prochaine lumière rouge qui doit être réparée.

  7. Contrairement à la croyance populaire, les tests unitaires ne signifient pas écrire deux fois plus de code ou coder plus lentement. C'est plus rapide et plus robuste que de coder sans tests une fois que vous avez compris. Le code de test en lui-même est généralement relativement trivial et n'ajoute pas grand-chose à ce que vous faites. C'est celui que vous ne croirez que lorsque vous le ferez :)

  8. Je pense que c'est Fowler qui a dit: «Les tests imparfaits, exécutés fréquemment, sont bien meilleurs que les tests parfaits qui ne sont jamais écrits du tout». J'interprète ceci comme me donnant la permission d'écrire des tests où je pense qu'ils seront les plus utiles même si le reste de ma couverture de code est terriblement incomplète.

  9. De bons tests unitaires peuvent aider à documenter et définir ce que quelque chose est censé faire

  10. Les tests unitaires aident à la réutilisation du code. Migrez à la fois votre code et vos tests à votre nouveau projet. Tweak le code jusqu'à ce que les tests s'exécutent à nouveau.

Une grande partie du travail auquel je participe n'est pas un bon test d'unité (interactions entre utilisateurs d'applications Web, etc.), mais nous sommes tous infectés par le test dans cette boutique, et plus heureux quand nos tests sont bloqués. Je ne peux pas recommander suffisamment l'approche.


722



Les tests unitaires, c'est un peu comme aller au gym.  Vous savez que c'est bon pour vous, tous les arguments ont un sens, alors vous commencez à vous entraîner. Il y a une première poussée, ce qui est génial, mais après quelques jours, vous commencez à vous demander si cela en vaut la peine. Vous prenez une heure de votre journée pour changer de vêtements et courir sur une roue de hamster et vous n'êtes pas sûr de vraiment gagner autre chose que des jambes et des bras endoloris.

Puis, après peut-être une ou deux semaines, tout comme la douleur disparaît, une grande date limite approche. Vous devez passer chaque heure éveillée à essayer de faire un travail «utile», afin de supprimer des choses superflues, comme aller à la gym. Vous tombez en dehors de l'habitude, et au moment où Big Deadline est terminée, vous êtes de retour à la case départ. Si vous parvenez à revenir à la salle de gym du tout, vous vous sentez aussi douloureux que vous étiez la première fois que vous êtes allé.

Vous lisez, pour voir si vous faites quelque chose de mal. Vous commencez à ressentir un peu de dépit irrationnel envers tous ceux qui sont en forme, des gens heureux vantant les vertus de l'exercice. Vous réalisez que vous n'avez pas beaucoup en commun. Ils n'ont pas à conduire 15 minutes pour aller à la gym; il y en a un dans leur immeuble. Ils n'ont pas à discuter avec qui que ce soit des avantages de l'exercice; c'est juste quelque chose que tout le monde fait et accepte comme important. Lorsqu'une grande date limite approche, on ne leur dit pas que l'exercice n'est pas plus nécessaire que votre patron vous demanderait d'arrêter de manger.

Donc, pour répondre à votre question, les tests unitaires en valent généralement la peine, mais l'effort requis ne sera pas le même pour tout le monde.  Les tests unitaires peuvent exiger beaucoup d'efforts si vous avez affaire à un code spaghetti dans une entreprise qui ne réellement la qualité du code de valeur. (Beaucoup de gestionnaires vont chanter les éloges d'Unit Testing, mais cela ne veut pas dire qu'ils vont le supporter quand ça compte.)

Si vous essayez d'introduire des tests unitaires dans votre travail et que vous ne voyez pas tous les rayons de soleil et les arcs-en-ciel auxquels vous êtes habitués, ne vous blâmez pas. Vous pourriez avoir besoin de trouver un nouveau travail pour vraiment faire fonctionner les tests unitaires pour vous.


421



La meilleure façon de convaincre ... de trouver un bug, d'écrire un test unitaire, de corriger le bug.

Ce bug particulier est peu susceptible d'apparaître à nouveau, et vous pouvez le prouver avec votre test.

Si vous le faites assez, les autres vont vite se faire remarquer.


136



thetalkingwalnut demande:

Quels sont les bons moyens de convaincre les développeurs sceptiques de l'équipe de la valeur de Unit Testing?

Tout le monde ici va accumuler beaucoup de raisons à l'improviste pourquoi les tests unitaires sont bons. Cependant, je trouve souvent que le meilleur moyen de convaincre quelqu'un de quelque chose est de écouter à leur argumentation et l'adresse point par point. Si vous les écoutez et les aidez à exprimer leurs préoccupations, vous pouvez les aborder et peut-être les convertir à votre point de vue (ou, à tout le moins, les laisser sans jambe pour se tenir debout). Qui sait? Peut-être qu'ils vous convaincront pourquoi les tests unitaires ne sont pas adaptés à votre situation. Pas probable, mais possible. Peut-être que si vous postez leurs arguments contre des tests unitaires, nous pouvons aider à identifier les contre-arguments.

Il est important d'écouter et de comprendre les deux côtés de l'argument. Si vous essayez d'adopter des tests unitaires avec trop de zèle sans tenir compte des préoccupations des gens, vous finirez avec une guerre de religion (et probablement des tests unitaires sans valeur). Si vous l'adoptez lentement et commencez par l'appliquer là où vous verrez le plus d'avantages au moindre coût, vous pourrez peut-être démontrer la valeur des tests unitaires et avoir une meilleure chance de convaincre les gens. Je me rends compte que ce n'est pas aussi facile que ça en a l'air - il faut généralement du temps et des mesures précises pour élaborer un argument convaincant.

Les tests unitaires sont un outil, comme les autres, et doivent être appliqués de manière à ce que les bénéfices (les bugs de capture) l'emportent sur les coûts (l'effort de les écrire). Ne les utilisez pas si / où ils n'ont pas de sens et rappelez-vous qu'ils ne sont qu'une partie de votre arsenal d'outils (par exemple, inspections, assertions, analyseurs de code, méthodes formelles, etc.). Ce que je dis à mes développeurs est ceci:

  1. Ils peuvent passer un test pour une méthode s'ils ont un bon argument pour expliquer pourquoi cela n'est pas nécessaire (par exemple trop simple pour le valoir ou trop difficile pour le valoir) et comment la méthode sera vérifiée (par exemple, inspection, assertions , méthodes formelles, tests interactifs / d'intégration). Ils doivent considérer que certaines vérifications comme les inspections et les preuves formelles sont faites à un moment donné et doivent ensuite être répétées chaque fois que le code de production change, tandis que les tests unitaires et les assertions peuvent être utilisés comme tests de régression. ). Parfois, je suis d'accord avec eux, mais plus souvent je vais débattre de la question de savoir si une méthode est vraiment trop simple ou trop difficile à tester unitaire.

    • Si un développeur fait valoir qu'une méthode semble trop simple pour échouer, cela ne vaut-il pas la peine de prendre les 60 secondes nécessaires pour rédiger un simple test unitaire de 5 lignes? Ces 5 lignes de code fonctionneront tous les soirs (vous faites des batailles nocturnes, n'est-ce pas?) Pour l'année suivante ou plus et cela en vaudra la peine si seulement une fois arrive à attraper un problème qui a pris 15 minutes ou plus pour identifier et déboguer. En outre, écrire les tests unitaires faciles augmente le nombre de tests unitaires, ce qui rend le développeur bien paraître.

    • D'un autre côté, si un développeur argumente qu'une méthode semble trop difficile à tester (ne vaut pas l'effort significatif requis), c'est peut-être une bonne indication que la méthode doit être divisée ou refactorisée pour tester les parties faciles. Habituellement, ce sont des méthodes qui s'appuient sur des ressources inhabituelles comme les singletons, l'heure actuelle, ou des ressources externes comme un ensemble de résultats de base de données. Ces méthodes doivent généralement être refactorisées en une méthode qui récupère la ressource (par exemple, appels getTime ()) et une méthode qui prend la ressource en tant qu'argument (par exemple prend l'horodatage en tant que paramètre). Je les laisse passer le test de la méthode qui récupère la ressource et écrit à la place un test unitaire pour la méthode qui prend maintenant la ressource en argument. Habituellement, cela rend l'écriture du test unitaire beaucoup plus simple et donc intéressante à écrire.

  2. Le développeur doit tracer une «ligne dans le sable» dans la mesure où leurs tests unitaires devraient être complets. Plus tard dans le développement, chaque fois que nous trouvons un bug, ils devraient déterminer si des tests unitaires plus complets auraient permis de résoudre le problème. Si c'est le cas et si de tels bugs surgissent à plusieurs reprises, ils doivent déplacer la «ligne» vers l'écriture de tests unitaires plus complets dans le futur (en commençant par ajouter ou étendre le test unitaire du bogue actuel). Ils ont besoin de trouver le bon équilibre.

Il est important de réaliser les tests unitaires ne sont pas une balle d'argent et il est une telle chose comme trop de tests unitaires. Sur mon lieu de travail, chaque fois que nous faisons des leçons apprises, j'entends inévitablement «nous devons écrire plus de tests unitaires». La direction acquiesce d'un signe de tête parce qu'on lui a cogné la tête que «tests unitaires» == «bien».

Cependant, nous devons comprendre l'impact de «plus de tests unitaires». Un développeur ne peut écrire que ~ N lignes de code par semaine et vous devez déterminer quel pourcentage de ce code doit être un code de test unitaire par rapport au code de production. Un poste de travail laxiste peut avoir 10% du code en tant que tests unitaires et 90% du code en tant que code de production, résultant en un produit avec beaucoup de fonctionnalités (bien que très buggué) (pensez MS Word). D'autre part, un magasin strict avec 90% de tests unitaires et 10% de code de production aura un produit solide avec peu de fonctionnalités (pensez "vi"). Vous pouvez ne jamais entendre des rapports sur le fait que ce dernier produit plante, mais cela a probablement autant à voir avec le produit qui ne se vend pas très bien autant que cela a à voir avec la qualité du code.

Pire encore, peut-être la seule certitude dans le développement de logiciels est que "le changement est inévitable". Supposons que le magasin strict (90% de tests unitaires / 10% de code de production) crée un produit ayant exactement 2 caractéristiques (en supposant 5% du code de production == 1 caractéristique). Si le client arrive et modifie 1 des fonctionnalités, alors ce changement détruit 50% du code (45% des tests unitaires et 5% du code de production). La boutique laxiste (10% tests unitaires / 90% code de production) a un produit avec 18 fonctionnalités, dont aucune ne fonctionne très bien. Leur client réorganise complètement les exigences pour 4 de leurs fonctionnalités. Même si le changement est 4 fois plus important, seulement la moitié de la base du code est détruite (~ 25% = ~ 4,4% de tests unitaires + 20% de code de production).

Ce que je veux dire, c'est que vous devez communiquer que vous comprenez l'équilibre entre trop peu et trop de tests unitaires - essentiellement que vous avez réfléchi aux deux côtés de la question. Si vous pouvez convaincre vos pairs et / ou votre gestion de cela, vous gagnez de la crédibilité et avez peut-être une meilleure chance de les gagner.


69



J'ai joué plusieurs fois avec des tests unitaires, et je suis toujours convaincu que cela en vaut la peine compte tenu de ma situation.

Je développe des sites Web, où une grande partie de la logique implique la création, la récupération ou la mise à jour des données dans la base de données. Quand j'ai essayé de "simuler" la base de données à des fins de tests unitaires, cela a été très compliqué et semblait un peu inutile.

Quand j'ai écrit des tests unitaires autour de la logique métier, cela ne m'a jamais vraiment aidé à long terme. Parce que je travaille principalement sur des projets, j'ai tendance à savoir intuitivement quels domaines du code peuvent être affectés par quelque chose sur lequel je travaille, et je teste ces zones manuellement. Je veux offrir une solution à mon client le plus rapidement possible, et les tests unitaires semblent souvent une perte de temps. J'énumère les tests manuels et je les parcours moi-même, en les cochant au fur et à mesure.

Je peux voir que cela peut être bénéfique lorsqu'une équipe de développeurs travaille sur un projet et met à jour le code de l'autre, mais même alors je pense que si les développeurs sont de haute qualité, une bonne communication et un code bien écrit devraient souvent suffire .


38



Une bonne chose à propos des tests unitaires, c'est qu'ils servent de documentation sur la façon dont votre code est censé se comporter. Les bons tests sont un peu comme une implémentation de référence, et les coéquipiers peuvent les regarder pour voir comment intégrer leur code avec le vôtre.


31



Les tests unitaires valent bien l'investissement initial. Depuis que j'ai commencé à utiliser les tests unitaires il y a quelques années, j'ai trouvé de réels avantages:

  • les tests de régression enlève la peur de apporter des modifications au code (il n'y a rien comme la lueur chaude de voir le code travailler ou exploser chaque fois qu'un changement est fabriqué)
  • exemples de code exécutable pour les autres membres de l'équipe (et vous-même dans six mois de temps ..)
  • sans merci refactoring - C'est incroyablement gratifiant, essayez-le!

Les extraits de code peuvent être d'une grande aide pour réduire les frais généraux liés à la création de tests. Il n'est pas difficile de créer des extraits qui permettent la création d'un contour de classe et d'un appareil de test d'unité associé en quelques secondes.


26



Vous devriez tester le moins possible!

ce qui signifie, vous devez écrire juste assez de tests unitaires pour révéler l'intention. Cela est souvent passé sous silence. Les tests unitaires vous coûtent. Si vous faites des changements et que vous devez changer de test, vous serez moins agile. Gardez les tests unitaires courts et doux. Ensuite, ils ont beaucoup de valeur.

Trop souvent, je vois beaucoup de tests qui ne se briseront jamais, sont gros et maladroits et n'offrent pas beaucoup de valeur, ils finissent par vous ralentir.


25



Je n'ai vu cela dans aucune des autres réponses, mais une chose que j'ai remarquée est que Je pourrais déboguer beaucoup plus vite. Vous n'avez pas besoin de naviguer dans votre application avec la bonne séquence d'étapes pour obtenir le code de votre solution, seulement pour constater que vous avez fait une erreur booléenne et que vous devez tout recommencer. Avec un test unitaire, vous pouvez simplement entrer directement dans le code que vous déboguez.


23