Le test unitaire en vaut-il la peine?
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 des tests unitaires? Dans mon cas particulier, nous ajouterions des tests unitaires au fur et à mesure que nous ajouterions des fonctionnalités ou corrigerions des bugs. Malheureusement, notre base de code ne se prête pas à des tests faciles.
Chaque jour dans notre bureau, il y a un échange qui se passe comme ceci:
"Mec, j'adore les tests unitaires, je viens juste de faire un tas de changements dans le fonctionnement de quelque chose, puis j'ai pu confirmer que je n'avais rien cassé en refaisant les tests ..."
Les détails changent tous les jours, mais pas le sentiment. Les tests unitaires et le développement piloté par les tests (TDD) présentent de nombreux avantages cachés et personnels, ainsi que des avantages évidents que vous ne pouvez tout simplement pas expliquer à quelqu'un avant qu'il ne le fasse lui-même.
Mais, ignorant cela, voici ma tentative!
Les tests unitaires vous permettent de modifier rapidement le code. Vous savez que cela fonctionne maintenant parce que vous avez exécuté les tests. Lorsque vous apportez les modifications nécessaires, vous devez les faire fonctionner à nouveau. Cela économise des heures.
TDD vous aide à comprendre quand arrêter de coder. Vos tests vous donnent l’assurance que vous en avez fait assez pour le moment et que vous pouvez cesser d’affiner et passer à la prochaine étape.
Les tests et le code fonctionnent ensemble pour obtenir un meilleur code. Votre code pourrait être mauvais/buggy. Votre test pourrait être mauvais/buggy. En TDD, vous misez sur les chances de les deux être mauvais/buggy étant faible. C'est souvent le test qui doit être corrigé, mais cela reste un bon résultat.
TDD aide à coder la constipation. Confrontés à une tâche importante et décourageante, les tests vous feront avancer rapidement.
Les tests unitaires vous aident à vraiment 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 résultats que vous attendez de cela.
Les tests unitaires vous donnent un retour visuel instantané, nous aimons tous la sensation de tous ces feux verts lorsque nous avons terminé. C'est très satisfaisant. Il est également beaucoup plus facile de reprendre votre travail après une interruption, car vous pouvez voir où vous en êtes, le prochain feu rouge à réparer.
Contrairement à la croyance populaire, les tests unitaires ne signifient pas écrire deux fois plus de code, ni coder plus lentement. C'est plus rapide et plus robuste que de coder sans tests une fois que vous avez compris le principe. Le code de test lui-même est généralement relativement trivial et n’ajoute pas de frais généraux importants à ce que vous faites. C’est celui que vous ne croirez que lorsque vous le ferez :)
Je pense que c'est Fowler qui a déclaré: "Les tests imparfaits, effectués fréquemment, sont bien meilleurs que les tests parfaits qui ne sont jamais écrits". J'interprète cela comme une permission de rédiger des tests là où je pense qu'ils seront le plus utiles même si le reste de la couverture de code que je propose est lamentablement incomplète.
De bons tests unitaires peuvent aider à documenter et à définir ce que quelque chose est censé faire.
Les tests unitaires aident à la réutilisation du code. Migrez votre code et vos tests vers votre nouveau projet. Tweak le code jusqu'à ce que les tests soient exécutés à nouveau.
Un grand nombre de tâches auxquelles je participe ne fonctionnent pas bien avec les tests unitaires (interactions entre utilisateurs d'applications Web, etc.), mais malgré cela, nous sommes tous infectés par les tests dans ce magasin, et le plus heureux quand nos tests sont terminés. Je ne peux pas recommander l'approche assez fortement.
Les tests unitaires, c'est un peu comme aller au gym. Vous savez que c'est bon pour vous, tous les arguments ont du sens, alors vous commencez à vous entraîner. Il y a un Rush initial, ce qui est excellent, 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 gagner quoi que ce soit d'autre que des douleurs aux jambes et aux bras.
Puis, après une ou deux semaines peut-être, alors que la douleur disparaît, une grande échéance approche. Vous devez passer chaque heure de votre réveil à essayer de faire un travail "utile", vous éviterez ainsi des tâches superflues, comme aller au gymnase. Vous perdez l'habitude et à la fin de Big Deadline, vous êtes de retour à la case départ. Si vous parvenez à retourner à la salle de gym, vous vous sentez aussi douloureux que la première fois que vous y êtes allé.
Vous lisez un peu pour voir si vous faites quelque chose de mal. Vous commencez à ressentir un peu de dépit irrationnel envers toutes les personnes en forme et heureuses 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 au gymnase; il y en a un dans leur immeuble. Ils n'ont pas à discuter avec quiconque 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 est inutile, pas plus que votre patron ne vous demanderait de cesser de manger.
Donc, pour répondre à votre question, les tests unitaires valent généralement la peine, mais les efforts nécessaires ne seront pas identiques pour tout le monde. Les tests unitaires peuvent nécessiter des efforts énormes si ont affaire à une base de code spaghetti dans une entreprise qui ne valorise pas la qualité du code. (Beaucoup de managers vont chanter les louanges des tests unitaires, mais cela ne signifie pas qu'ils vont le défendre quand ça compte.)
Si vous essayez d'introduire les tests unitaires dans votre travail et que vous ne voyez pas tout le soleil et les arcs-en-ciel auxquels vous êtes censés s'attendre, ne vous en prenez pas à vous-même. Vous devrez peut-être trouver un nouvel emploi pour que les tests unitaires fonctionnent vraiment pour vous.
Le meilleur moyen de convaincre ... trouvez un bogue, écrivez un test unitaire pour le corriger, corrigez le bogue.
Il est peu probable que ce bogue apparaisse de nouveau, et vous pouvez le prouver avec votre test.
Si vous faites cela assez, les autres vont rapidement comprendre.
thetalkingwalnut demande:
Quels sont les bons moyens de convaincre les développeurs sceptiques de l'équipe de la valeur des tests unitaires?
Tout le monde ici va s'expliquer sur de nombreuses raisons pour lesquelles les tests unitaires sont bons. Cependant, je trouve que souvent le meilleur moyen de convaincre quelqu'un de quelque chose est d'écouter son argument et de le traiter point par point. Si vous les écoutez et les aidez à exprimer leurs préoccupations, vous pouvez répondre à chacune d’elles et peut-être les convertir à votre point de vue (ou au moins les laisser sans jambe sur lesquelles elles se tiennent). Qui sait? Ils vous convaincront peut-être pourquoi les tests unitaires ne conviennent pas à votre situation. Peu probable, mais possible. Peut-être que si vous publiez leurs arguments contre les tests unitaires, nous pourrons vous 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 de la population, vous vous retrouverez avec une guerre de religion (et probablement des tests unitaires vraiment 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 cela en a l'air - cela nécessite généralement un peu de temps et des mesures méticuleuses pour élaborer un argument convaincant.
Les tests unitaires sont un outil, comme un autre, et doivent être appliqués de manière à ce que les avantages (élimination des bogues) l'emportent sur les coûts (l'effort nécessaire pour 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 (inspections, assertions, analyseurs de code, méthodes formelles, etc.). Voici ce que je dis à mes développeurs:
Ils peuvent ignorer l'écriture d'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 en valoir la peine ou trop difficile pour le mériter) et comment la méthode sera vérifiée d'une autre manière (par exemple, inspection, assertions , méthodes formelles, tests interactifs/d’intégration). Ils doivent tenir compte du fait que certaines vérifications, telles que des inspections et des preuves formelles, sont effectuées à un moment donné et doivent ensuite être répétées chaque fois que le code de production change, alors que les tests unitaires et les assertions peuvent être utilisés comme tests de régression (écrits une fois et exécutés de manière répétée par la suite). ) Parfois, je suis d’accord avec eux, mais plus souvent, je me demande si une méthode est vraiment trop simple ou trop difficile à tester.
Si un développeur affirme qu'une méthode semble trop simple pour échouer, 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 toutes les nuits (vous effectuez des versions nocturnes, n'est-ce pas?) Pendant un an ou plus et valent la peine si même une fois qu'un problème survient 15 minutes ou plus avant d'être identifié et déboguer. En outre, l'écriture des tests unitaires simples augmente le nombre de tests unitaires, ce qui donne au développeur une belle apparence.
D'un autre côté, si un développeur affirme qu'une méthode semble trop difficile à tester un peu (cela ne vaut pas l'effort considérable requis), c'est peut-être une bonne indication que la méthode doit être divisée ou remaniée pour tester les parties faciles. Il s'agit généralement de méthodes qui reposent sur des ressources inhabituelles telles que des singletons, l'heure actuelle ou des ressources externes telles qu'un jeu 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, appelle getTime ()) et une méthode qui prend la ressource en argument (par exemple, prend l'horodatage en tant que paramètre). Je les laisse ignorer le test de la méthode qui récupère la ressource et ils écrivent plutôt un test unitaire pour la méthode qui prend maintenant la ressource en argument. Habituellement, cela simplifie considérablement l’écriture du test unitaire et, par conséquent, vaut la peine d’écrire.
Le développeur doit tracer une "ligne du sable" dans la précision de ses tests unitaires. Plus tard dans le développement, chaque fois que nous trouverons un bogue, ils devront déterminer si des tests unitaires plus complets auraient permis de détecter le problème. Si tel est le cas et si de tels bogues apparaissent régulièrement, ils doivent déplacer la "ligne" vers l'écriture de tests unitaires plus complets à l'avenir (en commençant par l'ajout ou le développement du test unitaire pour le bogue actuel). Ils ont besoin de trouver le bon équilibre.
Il est important de réaliser que les tests unitaires ne sont pas une solution miracle et qu'il existe trop de trop de tests unitaires. Sur mon lieu de travail, chaque fois que nous tirons une leçon de mon expérience, j’entends inévitablement "nous devons écrire davantage de tests unitaires". La direction acquiesce de la tête parce que sa "test unitaire" == "bon" lui est tombé dans la tête.
Cependant, nous devons comprendre l'impact de "davantage 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 composé de code de test unitaire et de code de production. Un poste de travail laxiste peut avoir 10% du code sous forme de tests unitaires et 90% du code sous forme de code de production, ce qui donne un produit avec de nombreuses fonctionnalités (bien que très boguées) (pensez à MS Word). D'autre part, un magasin strict avec 90% de tests unitaires et 10% de code de production aura un produit solide comme le roc avec très peu de fonctionnalités (pensez "vi"). Vous n'entendrez peut-être jamais parler d'un crash de ce dernier produit, mais cela a probablement tout autant à voir avec le produit qui ne se vend pas très bien qu'avec la qualité du code.
Pire encore, la seule certitude en matière de développement logiciel 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 qui possède exactement 2 fonctionnalités (en supposant que 5% du code de production == 1 fonctionnalité). Si le client se présente et modifie 1 des fonctionnalités, cette modification supprime 50% du code (45% des tests unitaires et 5% du code de production). Le lax shop (10% de tests unitaires/90% de code de production) propose un produit avec 18 fonctions, dont aucune ne fonctionne très bien. Leur client réorganise complètement les exigences pour 4 de leurs fonctionnalités. Bien que le changement soit 4 fois plus important, seule la moitié de la base de code est supprimée (~ 25% = ~ 4,4% des tests unitaires + 20% du code de production).
Ce que je veux dire, c'est que vous devez communiquer que vous comprenez cet é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 réussissez à convaincre vos pairs et/ou votre direction, vous gagnez en crédibilité et avez peut-être une meilleure chance de les gagner.
J'ai joué avec les tests unitaires à plusieurs reprises et je suis toujours convaincu que cela en vaut la peine compte tenu de ma situation.
Je développe des sites Web où la logique consiste en grande partie à créer, récupérer ou mettre à jour des données dans la base de données. Lorsque j'ai essayé de "simuler" la base de données à des fins de tests unitaires, elle est devenue très compliquée et semblait un peu inutile.
Lorsque j'ai écrit des tests unitaires autour de la logique métier, cela ne m'a jamais vraiment aidé à long terme. Étant donné que je travaille en grande partie uniquement sur des projets, j'ai tendance à savoir intuitivement quels domaines du code peuvent être affectés par un élément sur lequel je travaille et je les teste manuellement. Je souhaite fournir une solution à mon client le plus rapidement possible et les tests unitaires semblent souvent une perte de temps. J'énumère des tests manuels et les parcoure moi-même, en les cochant au fur et à mesure.
Je peux voir que cela peut être bénéfique quand une équipe de développeurs travaille sur un projet et met à jour le code de l'autre, mais même dans ce cas, je pense que si les développeurs sont de haute qualité, une bonne communication et du code bien écrit devraient souvent suffire. .
L'un des avantages des tests unitaires est qu'ils servent à documenter le comportement de votre code. Les bons tests sont un peu comme une implémentation de référence, et les coéquipiers peuvent les consulter pour voir comment intégrer leur code avec le vôtre.
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 constaté de réels avantages:
- test de régression élimine la peur de modifier le code (rien ne vaut la lueur chaude de voir le code fonctionner ou exploser à chaque changement)
- exemples de code exécutable pour les autres membres de l'équipe (et vous-même dans six mois ..)
- sans merci refactoring - c'est incroyablement enrichissant, essayez-le!
Les fragments 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 de code qui permettent la création d'un contour de classe et d'un appareil de test unitaire associé en quelques secondes.
Vous devriez tester le moins possible!
cela signifie que vous devez écrire juste assez de tests unitaires pour révéler votre intention. Cela est souvent passé sous silence. Le test unitaire vous coûte. Si vous apportez des modifications et que vous devez modifier les tests, vous serez moins agile. Gardez les tests unitaires courts et faciles. 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 juste par vous ralentir.
Je ne l'ai pas vu dans aucune des autres réponses, mais une chose que j'ai remarquée est que je pourrais déboguer beaucoup plus rapidement. Vous n'avez pas besoin d'explorer votre application avec la bonne séquence d'étapes pour obtenir le code que vous corrigez, uniquement pour constater que vous avez commis 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.
[J'ai un point à faire que je ne peux pas voir ci-dessus]
"Tous les tests unitaires, ils ne le réalisent pas nécessairement - FACT"
Pensez-y, vous écrivez une fonction pour éventuellement analyser une chaîne et supprimer les nouveaux caractères de ligne. En tant que développeur débutant, vous pouvez exécuter quelques opérations depuis la ligne de commande en l'implémentant dans Main () ou associer une interface visuelle à un bouton et lier votre fonction à deux zones de texte et à un bouton. ce qui se produit.
Ce sont des tests unitaires - basiques et mal assemblés, mais vous testez le code dans quelques cas.
Vous écrivez quelque chose de plus complexe. Il génère des erreurs lorsque vous soumettez quelques cas (tests unitaires), que vous déboguez dans le code et que vous tracez. Vous examinez les valeurs au fur et à mesure et vous décidez si elles sont vraies ou fausses. C’est un peu les tests unitaires.
Les tests unitaires ici prennent vraiment ce comportement, le formalisant dans un motif structuré et le sauvegardant afin que vous puissiez facilement réexécuter ces tests. Si vous écrivez un "bon" cas de test unitaire plutôt que de le tester manuellement, cela prend le même temps, voire moins que l'expérience acquise, et vous avez la possibilité de le répéter encore et encore.
Pendant des années, j'ai essayé de convaincre les gens qu'ils devaient écrire un test unitaire pour leur code. Qu'ils aient écrit les tests en premier (comme dans TDD) ou après avoir codé la fonctionnalité, j'ai toujours essayé de leur expliquer tous les avantages des tests unitaires pour le code. Presque personne n'a été en désaccord avec moi. Vous ne pouvez pas ne pas être en désaccord avec quelque chose d'évident, et toute personne intelligente verra les avantages du test unitaire et du TDD.
Le problème des tests unitaires est qu’ils nécessitent un changement de comportement et qu’il est très difficile de changer le comportement des gens. Avec des mots, vous obtiendrez beaucoup de gens d'accord avec vous, mais vous ne verrez pas beaucoup de changements dans la façon dont ils font les choses.
Vous devez convaincre les gens en agissant. Votre succès personnel attirera plus de gens que tous les arguments que vous pourriez avoir. S'ils voient que vous ne parlez pas seulement de test unitaire ou de TDD, mais que vous faites ce que vous prêchez et que vous réussissez, les gens vont essayer de vous imiter.
Vous devez également assumer un rôle principal car personne n’écrit correctement les tests unitaires dès la première fois. Vous devrez donc peut-être leur expliquer comment le faire, leur montrer le chemin et les outils à leur disposition. Aidez-les pendant qu'ils écrivent leurs premiers tests, passez en revue les tests qu'ils écrivent eux-mêmes et montrez-leur les astuces, les idiomes et les patterns que vous avez appris à travers vos propres expériences. Après un certain temps, ils commenceront à voir les avantages par eux-mêmes et changeront de comportement pour incorporer des tests unitaires ou TDD dans leur boîte à outils.
Les changements ne se produiront pas du jour au lendemain, mais avec un peu de patience, vous pourrez atteindre votre objectif.
L'écriture de code testable est une partie importante du développement piloté par les tests qui est souvent passée sous silence. Cela semble être une sorte de compromis au début, mais vous découvrirez que le code à tester est également modulaire, maintenable et lisible. Si vous avez encore besoin d’aide pour convaincre les gens this est une présentation simple et agréable des avantages du test unitaire.
Si votre base de code existante ne se prête pas aux tests unitaires et qu'elle est déjà en production, vous pourriez créer plus de problèmes que vous n'en résolvez en essayant de refactoriser tout votre code afin qu'il soit testable par unité.
Vous feriez peut-être mieux de déployer des efforts pour améliorer vos tests d'intégration. Il y a beaucoup de code disponible qui est simplement plus simple à écrire sans test unitaire, et si un contrôle qualité peut valider la fonctionnalité par rapport à un document d'exigences, vous avez terminé. Expédier.
L’exemple classique de ceci dans mon esprit est un SqlDataReader incorporé dans une page ASPX liée à un GridView. Le code est tout dans le fichier ASPX. Le SQL est dans une procédure stockée. Que testez-vous? Si la page fait ce qu'elle est censée faire, devriez-vous vraiment la redéfinir en plusieurs couches afin de pouvoir automatiser quelque chose?
Une des meilleures choses à propos des tests unitaires est que votre code deviendra plus facile à tester à mesure que vous le ferez. Le code préexistant créé sans tests est toujours un défi car, comme ils ne sont pas conçus pour être testés à l'unité, il n'est pas rare d'avoir un niveau élevé de couplage entre les classes, des objets difficiles à configurer dans votre classe, comme un courrier électronique. envoi référence de service - et ainsi de suite. Mais ne laissez pas cela vous abattre! Vous verrez que la conception globale de votre code s'améliorera au fur et à mesure que vous commencerez à écrire des tests unitaires, et plus vous testerez, plus vous aurez confiance en sa capacité à apporter encore plus de modifications sans craindre de vous casser à l'application ou de créer des bogues. .
Il existe plusieurs raisons pour tester votre code, mais au fil du temps, vous constaterez que le temps que vous économisez sur les tests est l'une des meilleures raisons de le faire. Dans un système que je viens de livrer, j'ai insisté pour effectuer des tests unitaires automatisés malgré les affirmations selon lesquelles je passerais beaucoup plus de temps à effectuer les tests que je ne le ferais en testant le système manuellement. Avec tous mes tests unitaires terminés, j'ai exécuté plus de 400 cas de test en moins de 10 minutes, et chaque fois que je devais faire une petite modification dans le code, il me suffisait d'être certain que le code fonctionnait toujours sans bogues minutes. Pouvez-vous imaginer le temps nécessaire pour exécuter manuellement ces 400 tests ou plus?
Lorsqu'il s'agit de tests automatisés, qu'il s'agisse de tests unitaires ou de tests d'acceptation, tout le monde pense qu'il est inutile de coder manuellement ce que vous pouvez faire, ce qui est parfois vrai si vous prévoyez d'exécuter vos tests une seule fois. La meilleure partie des tests automatisés est que vous pouvez les exécuter plusieurs fois sans effort, et après la deuxième ou la troisième exécution, le temps et les efforts que vous avez perdus est déjà payé.
Un dernier conseil serait non seulement de tester votre code à l’unité, mais de commencer par le faire d’abord (voir TDD et BDD pour plus)
Les tests unitaires sont aussi particulièrement utiles lorsqu'il s'agit de refactoriser ou de réécrire une pièce ou un code. Si vous avez une bonne couverture de tests unitaires, vous pouvez refactoriser en toute confiance. Sans tests unitaires, il est souvent difficile de s’assurer de ne rien casser.
Je travaille en tant qu'ingénieur de maintenance dans une base de code mal documentée, terrible et volumineuse. J'espère que les auteurs du code ont passé les tests unitaires correspondants.
Chaque fois que je modifie et met à jour le code de production, je crains d’introduire un bogue pour ne pas avoir pris en compte une condition.
S'ils écrivaient le test, il serait plus facile et plus rapide de modifier la base de code (dans le même temps, la base de code serait dans un meilleur état).
Je pense que les tests unitaires s'avèrent très utiles pour écrire des API ou des frameworks qui doivent durer de nombreuses années et être utilisés/modifiés/développés par des personnes autres que les codeurs d'origine.
En bref - oui. Ils valent chaque once d'effort ... jusqu'à un certain point. Les tests sont, à la fin de la journée, toujours du code et, tout comme la croissance du code typique, vos tests devront éventuellement être refactorisés pour être maintenus et durables. Il y a une tonne de GOTCHAS! en ce qui concerne les tests unitaires, mais man oh man oh man, rien, et je veux dire, RIEN ne permet à un développeur d’apporter des modifications avec plus de confiance qu’un ensemble riche de tests unitaires.
Je travaille sur un projet en ce moment ... c'est un peu TDD, et nous avons la majorité de nos règles métier encapsulées sous forme de tests ... nous avons environ 500 tests unitaires à l'heure actuelle. Lors de la dernière itération, j'ai dû réorganiser notre source de données et la manière dont notre application de bureau s'interface avec cette source de données. Cela m'a pris quelques jours, tout le temps que je continuais à exécuter des tests unitaires pour voir ce que je cassais et le réparer. Faire un changement; Construisez et exécutez vos tests; réparer ce que vous avez cassé. Laver, rincer, répéter si nécessaire. Ce qui aurait pris traditionnellement des journées d’assurance qualité et une charge de stress importante en bateau était plutôt une expérience courte et agréable.
Préparez-vous à l’avant, avec un peu d’effort supplémentaire, et vous payerez 10 fois plus tard lorsque vous devrez commencer à vous défiler avec les principales fonctionnalités.
J'ai acheté ce livre - c'est une bible de la connaissance de xUnit Testing - c'est probablement l'un des livres les plus référencés de mon étagère, et je le consulte quotidiennement: lien texte
Parfois, soit moi-même, soit l'un de mes collègues, nous passons quelques heures à découvrir un bogue légèrement obscur et une fois que la cause du bogue est trouvée, 90% du temps où le code n'est pas testé par unité. Le test unitaire n'existe pas car le dev est en train d'économiser du temps pour gagner du temps, mais il perd alors cela et plus de débogage.
Prendre le peu de temps nécessaire pour écrire un test unitaire peut économiser des heures de débogage futur.
Lorsque vous avez dit, "notre base de code ne se prête pas à des tests faciles" est le premier signe d'une odeur de code. Écrire des tests unitaires signifie que vous écrivez généralement du code différemment afin de le rendre plus testable. C'est une bonne chose à mon avis, car ce que j'ai vu au fil des ans en écrivant du code pour lequel je devais écrire des tests, cela m'a obligé à proposer un meilleur design.
Je ne sais pas. Beaucoup d'endroits ne font pas de tests unitaires, mais la qualité du code est bonne. Microsoft effectue des tests unitaires, mais Bill Gates a donné un écran bleu lors de sa présentation.
Les tests unitaires en valent vraiment la peine. Malheureusement, vous avez choisi un scénario difficile (mais malheureusement commun) dans lequel le mettre en œuvre.
Le meilleur avantage des tests unitaires que vous obtiendrez est son utilisation intégrale: sur quelques projets sélectionnés, j'ai eu la chance d'écrire mes tests unitaires avant d'implémenter mes cours (l'interface était déjà complète à ce stade). point). Avec des tests unitaires appropriés, vous trouverez et corrigerez les bogues dans vos classes alors qu’elles en sont encore à leurs balbutiements et qu’elles ne sont pas proches du système complexe dans lequel elles seront sans aucun doute intégrées.
Si votre logiciel est résolument orienté objet, vous devriez pouvoir ajouter des tests unitaires au niveau de la classe sans trop d'effort. Si vous n'avez pas cette chance, vous devriez quand même essayer d'incorporer les tests unitaires partout où vous le pouvez. Assurez-vous que lorsque vous ajoutez de nouvelles fonctionnalités, les nouvelles pièces sont bien définies avec des interfaces claires et vous constaterez que les tests unitaires vous facilitent la vie.
J'ai écrit un très gros billet de blog sur le sujet. J'ai constaté que les tests unitaires à eux seuls ne valaient pas la peine d'être travaillés et étaient généralement éliminés lorsque les délais se rapprochaient.
Au lieu de parler de tests unitaires du point de vue de la vérification "test-after", nous devrions examiner la valeur vraie trouvée lorsque vous avez l'intention d'écrire une spéc/test/idée avant l'implémentation.
Cette idée simple a changé ma façon d'écrire un logiciel et je ne reviendrais pas à la "vieille" façon.
Une chose que personne n'a encore mentionnée est d'obtenir l'engagement de tous les développeurs pour exécuter et mettre à jour tout test automatisé existant. Les tests automatisés que vous retrouvez et que vous trouvez cassés à cause de nouveaux développements perdent beaucoup de valeur et rendent les tests automatisés très pénibles. La plupart de ces tests n'indiqueront pas de bugs puisque le développeur a testé le code manuellement, le temps passé à les mettre à jour est donc une perte de temps.
Convaincre les sceptiques de ne pas détruire le travail que font les autres lors des tests unitaires est beaucoup plus important pour tirer le meilleur parti des tests et pourrait être plus facile.
Passer des heures à mettre à jour des tests rompus à cause de nouvelles fonctionnalités chaque fois que vous mettez à jour à partir du référentiel n’est ni productif ni amusant.
J'ai découvert le TDD il y a quelques années et, depuis, j'ai écrit tous mes projets pour animaux de compagnie en l'utilisant. J’ai estimé qu’il fallait à peu près autant de temps au projet TDD qu’à un cow-boy ensemble, mais j’ai une telle confiance dans le produit final que je ne peux pas m'empêcher d’avoir un sentiment de réussite.
Je pense aussi que cela améliore mon style (beaucoup plus axé sur l'interface au cas où je devrais me moquer de choses ensemble) et, comme l'écrit le billet vert en haut, cela aide à "coder la constipation": quand on ne sait pas quoi pour écrire ensuite, ou si vous avez une tâche ardue devant vous, vous pouvez écrire petit.
Enfin, je trouve que l’application la plus utile de TDD est de loin celle du débogage, ne serait-ce que parce que vous avez déjà développé un cadre d’interrogation avec lequel vous pouvez inciter le projet à produire le bogue de manière répétable.
Oui, les tests unitaires en valent vraiment la chandelle, mais sachez que ce n'est pas une solution miracle. Le test unitaire est un travail et vous devrez travailler pour maintenir le test à jour et pertinent au fur et à mesure que le code change, mais la valeur offerte en vaut la chandelle. La possibilité de refactoriser impunément est un avantage énorme, car vous pouvez toujours valider les fonctionnalités. en exécutant vos tests après tout changement de code. L'astuce consiste à ne pas trop vous accrocher à l'unité de travail que vous testez ou à la manière dont vous répondez aux exigences de test d'échafaudage et lorsqu'un test d'unité est vraiment un test fonctionnel, etc. Les gens vont se disputer à ce sujet pendant des heures. et la réalité est que tout test que vous faites en tant que votre code d’écriture est préférable à ne pas le faire. L'autre axiome concerne la qualité et non la quantité - j'ai vu des bases de code avec des milliers de tests qui sont essentiellement dépourvues de sens, car les autres ne testent vraiment rien d'utile ou de domaine spécifique comme les règles commerciales, etc. du domaine en question. J'ai également vu des bases de code avec une couverture de code de 30%, mais les tests étaient pertinents, significatifs et vraiment géniaux, car ils testaient la fonctionnalité principale du code pour lequel il avait été écrit et indiquait comment le code devait être utilisé.
L’un de mes trucs préférés lors de l’exploration de nouveaux frameworks ou de nouvelles bases de code est d’écrire des tests unitaires afin de découvrir le fonctionnement des choses. C'est un excellent moyen d'en apprendre plus sur quelque chose de nouveau au lieu de lire un document sec :)
J'ai récemment vécu exactement la même expérience sur mon lieu de travail et j'ai constaté que la plupart d'entre eux connaissaient les avantages théoriques mais devaient être vendus spécifiquement pour eux. Voici donc les points que j'ai utilisés (avec succès):
- Ils permettent de gagner du temps lors des tests négatifs, dans lesquels vous gérez des entrées inattendues (pointeurs nuls, valeurs hors limites, etc.), comme vous pouvez le faire en un seul processus.
- Ils fournissent une rétroaction immédiate au moment de la compilation concernant la norme des modifications.
- Ils sont utiles pour tester les représentations de données internes qui peuvent ne pas être exposées lors de l'exécution normale.
et le grand ...
- Vous n’avez peut-être pas besoin de tests unitaires, mais si une autre personne modifie le code sans la comprendre parfaitement, elle risque de contenir beaucoup des erreurs stupides qu’elle pourrait commettre.
D'après mon expérience, les tests unitaires et les tests d'intégration sont un "MUST HAVE" dans des environnements logiciels complexes.
Afin de convaincre les développeurs de votre équipe de rédiger des tests unitaires, vous pouvez envisager d'intégrer l'analyse de régression de tests unitaires dans votre environnement de développement (par exemple, dans votre processus de construction quotidien).
Une fois que les développeurs savent que si un test unitaire échoue, ils n'ont pas à passer autant de temps à le déboguer pour trouver le problème, ils sont davantage encouragés à les écrire.
Voici un outil qui fournit une telle fonctionnalité:
Si vous utilisez NUnit, une démonstration simple mais efficace consiste à exécuter la ou les suites de tests de NUnit devant elles. Voir une vraie suite de tests donner à une base de code un entraînement vaut mille mots ...
Une chose à garder à l'esprit à propos des tests unitaires est que c'est un confort pour le développeur.
En revanche, les tests fonctionnels sont destinés aux utilisateurs: chaque fois que vous ajoutez un test fonctionnel, vous testez quelque chose que l'utilisateur verra. Lorsque vous ajoutez un test unitaire, vous vous simplifiez la vie en tant que développeur. C'est un peu un luxe à cet égard.
Gardez cette dichotomie à l'esprit lorsque vous devez choisir entre écrire une unité ou un test fonctionnel.
Je suis d'accord avec le point de vue opposé à la majorité ici: Ce n'est pas grave de ne pas écrire de tests unitaires Il est difficile de combiner une programmation très lourde en prototypes (AI, par exemple) avec des tests unitaires.
Le test unitaire aide beaucoup dans les projets de taille supérieure à ce qu'un développeur peut garder en tête. Ils vous permettent d'exécuter la suite de tests unitaires avant l'enregistrement et de découvrir si vous avez cassé quelque chose. Cela réduit considérablement beaucoup les cas où vous devez vous asseoir et vous tournez les pouces en attendant que quelqu'un corrige un bogue qu'ils ont enregistré, ou qui vous oblige à annuler leur modification pour pouvoir travailler. terminé. C'est également extrêmement précieux pour la refactorisation, vous pouvez donc être sûr que le code refactorisé passe tous les tests que le code d'origine a fait.
Avec la suite de tests unitaires, il est possible d’apporter des modifications au code tout en laissant intactes les fonctionnalités restantes. C'est un grand avantage. Utilisez-vous la suite de tests de sutie et de tests de régression lorsque vous avez fini de coder une nouvelle fonctionnalité?.
Le but des tests unitaires est de faciliter les tests. C'est automatisé. "make test" et vous avez terminé. Si l’un des problèmes auxquels vous êtes confronté est difficile à tester, c’est la meilleure raison pour utiliser le test unitaire.
Aujourd'hui encore, j'ai dû changer de classe pour laquelle un test unitaire avait déjà été écrit.
Le test lui-même était bien écrit et comprenait des scénarios de test auxquels je n'avais même pas pensé.
Heureusement, tous les tests ont réussi et mon changement a été rapidement vérifié et placé dans l'environnement de test en toute confiance.
Lorsque vous testez manuellement un logiciel, vous utilisez normalement un petit ensemble de tests/actions. Vous finirez par transformer automatiquement vos données d'entrée ou vos actions afin de pouvoir naviguer vous-même autour des problèmes connus. Les tests unitaires doivent être là pour vous rappeler que les choses ne fonctionnent pas correctement.
Je recommande d'écrire des tests avant le code, en ajoutant de nouveaux tests/données pour faire évoluer les fonctionnalités du code principal!
En tant qu'étudiant en physique, je suis très motivé pour réellement prouver que mon code fonctionne comme il est supposé. Vous pouvez soit le prouver de manière logique, ce qui augmente considérablement la difficulté à mesure que la mise en œuvre devient plus complexe, ou vous pouvez apporter une preuve empirique de la fonction (aussi proche que possible) au moyen de bons tests.
Si vous ne fournissez pas de preuve logique de fonctionnement, vous devez tester. La seule alternative est de dire "Je pense que le code fonctionne ...."
@ George Stocker "Malheureusement, notre base de code ne se prête pas à des tests faciles.". Tout le monde convient que les tests unitaires présentent des avantages, mais il semble que les coûts sont élevés pour cette base de code. Si les coûts sont supérieurs aux avantages, alors pourquoi devraient-ils être enthousiastes? Écoutez vos collègues. peut-être pour eux que la douleur perçue des tests unitaires est supérieure à la valeur perçue des tests unitaires.
Plus précisément, essayez de gagner de la valeur dès que possible, et non de la valeur "xUnit is green", mais du code propre que les utilisateurs et les responsables de la maintenance apprécient. Vous devrez peut-être imposer des tests unitaires pour une itération, puis déterminer si cela en vaut la peine ou non.
Faites en sorte que les premières choses que vous testez ne soient pas liées aux tests unitaires. Je travaille principalement en Perl, ce sont donc des exemples spécifiques à Perl, mais vous pouvez vous adapter.
Est-ce que chaque module charge et compile correctement? En Perl, il s’agit de créer un fichier Foo.t pour chaque fichier Foo.pm dans la base de code qui:
use_ok( 'Foo' );Tous les POD (Plain Ol 'Documentation) sont-ils correctement formatés? Utilisez Test :: Pod pour valider la validité du formatage de tous les POD de tous les fichiers.
Vous ne pensez peut-être pas qu'il s'agit de grandes choses, mais ce n'est pas le cas, mais je peux vous garantir que vous allez attraper des pertes. Lorsque ces tests sont exécutés une fois par heure et qu'il détecte la validation prématurée de quelqu'un, vous faites dire aux gens: "Hé, c'est plutôt cool."
L'un des avantages des tests unitaires est la prévisibilité.
Avant les tests unitaires, j'aurais pu prédire avec une grande précision combien de temps il faudrait pour coder quelque chose, mais pas combien de temps il me faudrait pour le déboguer.
Ces jours-ci, étant donné que je peux planifier les tests que je vais écrire, je sais combien de temps le codage va durer et, à la fin du codage, le système est déjà débogué! Cela apporte de la prévisibilité au processus de développement, ce qui supprime beaucoup de pression mais conserve tout de même la joie !!.
Le test unitaire est l'une des méthodologies les plus adoptées pour un code de haute qualité. Sa contribution à un code plus stable, indépendant et documenté est bien établie. Le code de test unitaire est considéré et traité comme une partie intégrante de votre référentiel et, en tant que tel, nécessite un développement et une maintenance. Cependant, les développeurs se trouvent souvent dans une situation où les ressources investies dans les tests unitaires n’ont pas été aussi fructueuses que prévu. Dans un monde idéal, chaque méthode que nous codons comportera une série de tests couvrant son code et validant son exactitude. Cependant, généralement en raison de contraintes de temps, nous ignorons certains tests ou en rédigeons des de mauvaise qualité. Dans une telle réalité, tout en tenant compte de la quantité de ressources investies dans le développement et la maintenance des tests unitaires, il convient de se demander, compte tenu du temps disponible, quel code mérite le plus d'être testé. Et parmi les tests existants, quels tests valent-ils réellement la peine de conserver? Voir ici
Les tests unitaires vous aident à publier des logiciels avec moins de bugs tout en réduisant les coûts de développement globaux. Vous pouvez cliquer sur le lien pour en savoir plus sur avantages des tests unitaires
Qui essayez-vous de convaincre? Ingénieurs ou manager? Si vous essayez de convaincre vos collègues ingénieurs, je pense que votre meilleur pari est de faire appel à leur désir de créer un logiciel de haute qualité. Il existe de nombreuses études montrant qu'il trouve des bugs et que si elles se soucient de faire du bon travail, cela devrait leur suffire.
Si vous essayez de convaincre la direction, vous devrez probablement faire un raisonnement coût/bénéfice indiquant que le coût des défauts qui ne seront pas détectés est supérieur au coût de la rédaction des tests. Assurez-vous d'inclure également les coûts intagables, tels que la perte de confiance des clients, etc.
C'est très net, mais quelqu'un a-t-il essayé Pex?
J'étais extrêmement sceptique jusqu'à ce que je l'essaie - et wow, quelle performance. Avant de penser "je ne vais pas être convaincu par ce concept tant que je ne comprend pas ce que fait réellement faire au profit de moi". Il a fallu une seule course pour que je change d’avis et dise: "Je ne me soucie pas de savoir comment il existe un risque d’exception fatale, mais là est et maintenant je sais que je dois m'en occuper "
Peut-être que le seul inconvénient de ce comportement est qu’il va signaler tout et vous donner un arriéré de six mois. Mais si vous aviez une dette de code, vous aviez toujours une dette de code, vous ne le saviez tout simplement pas. Dire un PM il y a deux cent mille points d’échec potentiels alors qu’avant, vous en connaissiez quelques dizaines, c’est une mauvaise perspective, ce qui signifie qu’il est essentiel que le concept soit a expliqué d'abord.