Les tests unitaires en valent-ils la peine?

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

“Man, j’adore les tests unitaires, j’ai juste pu apporter de nombreuses modifications à la manière dont fonctionne quelque chose, et j’ai pu confirmer que je n’avais rien cassé en faisant le test par-dessus …”

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 pas vraiment expliquer à quelqu’un avant de le faire lui-même.

Mais, en ignorant cela, voici ma tentative!

1. Les tests unitaires vous permettent de modifier rapidement le code. Vous savez que cela fonctionne maintenant car vous avez exécuté les tests, lorsque vous apportez les modifications nécessaires, vous devez relancer les tests. Cela économise des heures.

2. 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 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 / buggy. Votre test pourrait être mauvais / buggy. En TDD, vous comptez sur les chances que les deux soient mauvais / buggy étant faibles. Souvent, c’est le test à corriger, mais cela rest un bon résultat.

4. TDD aide à coder la constipation. Face à un travail de grande envergure et à venir, les tests vous permettront de vous déplacer rapidement.

5. Les tests unitaires vous aident à comprendre réellement 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 attendus.

6. Les tests unitaires vous donnent un retour visuel instantané, nous aimons tous la sensation de toutes ces lumières vertes lorsque nous avons terminé. C’est très satisfaisant. Il est aussi beaucoup plus facile de reprendre là où vous vous êtes arrêté après une interruption, car vous pouvez voir où vous en êtes – ce prochain feu rouge à réparer.

7. Contrairement aux croyances populaires, les tests unitaires ne signifient pas écrire deux fois plus de code, ni coder plus lentement. C’est plus rapide et plus robuste que le codage sans test une fois que vous avez tout compris. Le code de test lui-même est généralement relativement insignifiant et n’ajoute pas une grande importance à ce que vous faites. C’est celui-là 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 des tests parfaits qui ne sont jamais écrits du tout”. J’interprète cela comme me donnant la permission d’écrire des tests où je pense qu’ils seront les plus utiles même si le rest de la couverture de mon code est malheureusement incomplet.

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 vers votre nouveau projet. Tweak le code jusqu’à ce que les tests s’exécutent à nouveau.

Beaucoup de travail auquel je participe n’est pas très efficace (interactions utilisateur d’applications Web, etc.), mais malgré tout, nous sums tous infectés par le test dans cette boutique, et le plus heureux quand nous avons nos tests liés. Je ne peux pas recommander l’approche assez fortement.

Les tests unitaires, c’est comme aller au gymnase. Vous savez que c’est bon pour vous, tous les arguments ont du sens, alors vous commencez à vous entraîner. Il y a une précipitation initiale, 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 certain que vous ne gagnez rien d’autre que des jambes et des arm douloureux.

Puis, après peut-être une ou deux semaines, alors que la douleur disparaît, une grande échéance approche. Vous devez passer chaque heure à essayer d’obtenir un travail «utile», de sorte que vous coupiez des choses superflues, comme aller au gymnase. Vous perdez l’habitude et lorsque la grande date limite est terminée, vous êtes de retour à la case départ. Si vous parvenez à revenir à la salle de sport, vous vous sentez tout aussi douloureux que la première fois que vous êtes allé.

Vous faites des lectures pour voir si vous faites quelque chose de mal. Vous commencez à ressentir un peu de mécontentement irrationnel envers tous les gens heureux et heureux qui vantent les vertus de l’exercice. Vous vous rendez compte 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 quiconque des avantages de l’exercice; c’est juste quelque chose que tout le monde fait et accepte comme important. Lorsqu’une grande échéance approche, on ne leur dit pas que l’exercice n’est pas nécessaire, pas plus que votre patron ne vous demande de cesser de manger.

Donc, pour répondre à votre question, les tests unitaires en valent généralement la peine, mais la quantité d’efforts requirejse ne sera pas la même pour tout le monde. Les tests unitaires peuvent nécessiter des efforts énormes si vous traitez avec des codes spaghettis dans une entreprise qui ne valorise pas réellement la qualité du code. (Beaucoup de managers vont chanter les louanges des tests unitaires, mais cela ne signifie pas qu’ils le défendront quand il le faut.)

Si vous essayez d’introduire les tests unitaires dans votre travail et que vous ne voyez pas tous les rayons de soleil et les arcs-en-ciel auxquels vous avez été amené à vous attendre, ne vous en faites pas. Vous devrez peut-être trouver un nouvel emploi pour que les tests unitaires fonctionnent vraiment pour vous.

Meilleur moyen de convaincre … trouver un bogue, rédiger un test unitaire, corriger le bogue.

Il est peu probable que ce bug particulier réapparaisse, et vous pouvez le prouver avec votre test.

Si vous le faites assez, les autres vont vite 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 accumuler beaucoup de 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 ses arguments et de les aborder point par point. Si vous les écoutez et aidez-les à verbaliser leurs préoccupations, vous pouvez vous adresser à chacun et peut-être les convertir à votre sharepoint vue (ou, à tout le moins, les laisser sans jambe). Qui sait? Peut-être qu’ils vont vous convaincre pourquoi les tests unitaires ne sont pas adaptés à votre situation. Peu probable, mais possible. Peut-être que si vous affichez leurs arguments contre des tests unitaires, nous pouvons 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 des gens, vous vous retrouverez avec une guerre religieuse (et probablement des tests unitaires vraiment sans valeur). Si vous l’adoptez lentement et commencez par l’appliquer là où vous constaterez 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 simple que cela en a l’air – il faut 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 (attraper les bogues) dépassent les coûts (l’effort d’écriture). Ne les utilisez pas si / là où ils n’ont pas de sens et rappelez-vous qu’ils ne constituent qu’une partie de votre arsenal d’outils (par exemple, inspections, assertions, parsingurs de code, méthodes formelles, etc.). Ce que je dis à mes développeurs est la suivante:

1. Ils peuvent sauter un test pour une méthode s’ils ont un bon argument pour savoir pourquoi ce n’est pas nécessaire (par exemple, trop simple pour en valoir la peine ou trop difficile pour en valoir la peine) et comment la méthode sera vérifiée (inspection, assertions, etc.) , méthodes formelles, tests interactifs / d’intégration). Ils doivent considérer que certaines vérifications telles que les inspections et les preuves formelles sont effectuées à 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 ). Parfois, je suis d’accord avec eux, mais le plus souvent, je me demanderai si une méthode est trop simple ou trop difficile à tester.

   • Si un développeur soutient qu’une méthode semble trop simple pour échouer, ne vaut-il pas la peine de prendre les 60 secondes nécessaires pour écrire un test simple sur 5 lignes? Ces 5 lignes de code seront exécutées chaque nuit (vous faites des builds de nuit, non?) Pour l’année prochaine ou plus et en valent la peine si même une seule fois il détecte un problème qui a pris 15 minutes ou plus pour identifier et déboguer. En outre, l’écriture des tests unitaires simples augmente le nombre de tests unitaires, ce qui rend le développeur bien.

   • D’un autre côté, si un développeur soutient qu’une méthode semble trop difficile à tester (ne nécessitant pas l’effort considérable requirejs), c’est peut-être une bonne indication que la méthode doit être divisée ou modifiée pour tester les parties faciles. Généralement, ce sont des méthodes qui s’appuient sur des ressources inhabituelles telles que singletons, l’heure actuelle ou des ressources externes telles qu’un jeu de résultats de firebase database. Ces méthodes doivent généralement être remaniées dans une méthode qui obtient la ressource (par exemple, les appels getTime ()) et une méthode qui prend la ressource comme argument (par exemple, prend l’horodatage comme paramètre). Je les laisse sauter le test de la méthode qui récupère la ressource et écrivent plutôt un test unitaire pour la méthode qui prend maintenant la ressource comme 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 dans laquelle leurs tests unitaires doivent être complets. Plus tard dans le développement, chaque fois que nous trouvons un bogue, ils doivent déterminer si des tests unitaires plus complets auraient permis de résoudre le problème. Si tel est le cas et si de tels bogues surviennent à plusieurs resockets, ils doivent déplacer la “ligne” vers l’écriture de tests unitaires plus complets à l’avenir (en commençant par append ou étendre le test unitaire du bogue actuel). Ils doivent trouver le bon équilibre.

Il est important de réaliser que les tests unitaires ne sont pas une solution miracle et qu’il ya une trop grande quantité de tests unitaires. Sur mon lieu de travail, chaque fois que nous faisons des leçons apsockets, j’entends inévitablement «nous devons écrire plus de tests unitaires». La direction acquiesce parce que cela leur a été dit que “les tests unitaires” == “bons”.

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 ou un code de production. Un lieu de travail laxiste peut comporter 10% du code en tant que tests unitaires et 90% du code en tant que code de production, avec pour résultat un produit avec de nombreuses fonctionnalités (bien que très boguées) (pensez à MS Word). En revanche, un magasin ssortingct avec 90% de tests unitaires et 10% de code de production aura un produit solide avec très peu de fonctionnalités (pensez à “vi”). Il se peut que vous n’entendiez jamais de rapports sur la panne de ce produit, mais cela a probablement autant à voir avec le fait que le produit ne se vend pas très bien autant que la qualité du code.

Pire encore, la seule certitude dans le développement de logiciels est peut-être que “le changement est inévitable”. Supposons que l’atelier ssortingct (90% de tests unitaires / 10% de code de production) crée un produit comportant exactement 2 fonctionnalités (en supposant que 5% du code de production == 1). Si le client arrive et modifie 1 des fonctionnalités, cette modification entraîne 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) possède un produit avec 18 fonctionnalités, dont aucune ne fonctionne très bien. Leur client renouvelle complètement les exigences de 4 de ses fonctionnalités. Même si le changement est 4 fois plus important, la moitié seulement de la base de code est détruite (~ 25% = ~ 4,4% de tests unitaires + 20% du code de production).

Ce que je veux dire, c’est que vous devez comprendre que vous comprenez l’équilibre entre trop peu et trop de tests unitaires – essentiellement ce que vous avez pensé des deux côtés du problème. Si vous pouvez convaincre vos pairs et / ou votre direction de cela, vous gagnez en crédibilité et avez peut-être une meilleure chance de les gagner.

J’ai joué avec les tests unitaires à plusieurs resockets 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 de données dans la firebase database. Lorsque j’ai essayé de “me moquer” de la firebase database à des fins de tests unitaires, cela a été très compliqué 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. Parce que je travaille principalement sur des projets seuls, j’ai tendance à savoir intuitivement quelles zones de code peuvent être affectées par quelque chose sur lequel je travaille, et je teste ces zones manuellement. Je souhaite proposer une solution à mon client le plus rapidement possible et les tests unitaires semblent souvent une perte de temps. Je liste les tests manuels et les passe en revue 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. .

Une bonne chose à propos des tests unitaires est qu’ils servent de documentation sur la manière dont votre code doit 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.

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 suppriment la crainte de modifier le code (il n’y a rien de mieux que 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)
• refactoring impitoyable – c’est incroyablement gratifiant, essayez-le!

Les extraits de code peuvent être d’une grande aide pour réduire la surcharge de création de tests. Il n’est pas difficile de créer des extraits qui permettent de créer un plan de cours et un dispositif de test d’unité associé en quelques secondes.

Vous devriez tester le moins possible!

Autrement dit, 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 apportez des modifications et que vous devez modifier les tests, 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 casseront jamais, sont gros et maladroits et n’offrent pas beaucoup de valeur, ils finissent par vous ralentir.

Je ne l’ai vu dans aucune des autres réponses, mais une chose que j’ai remarquée, c’est que je pouvais déboguer beaucoup plus rapidement . Vous n’avez pas besoin de parcourir votre application avec la bonne séquence d’étapes pour accéder au code de votre correction, mais vous constatez que vous avez fait une erreur booléenne et que vous devez tout recommencer. Avec un test unitaire, vous pouvez simplement accéder directement au 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 forcément – FAIT”

Pensez-y, vous écrivez une fonction pour peut-être parsingr une chaîne et supprimer les nouveaux caractères de ligne. En tant que développeur débutant, vous exécutez quelques requêtes à partir de la ligne de commande en l’implémentant dans Main () ou vous associez ensemble un frontal avec un bouton, reliez votre fonction à quelques zones de texte et un bouton et voyez ce qui se produit.

C’est un test unitaire – basique et mal assemblé, mais vous testez le code pour quelques cas.

Vous écrivez quelque chose de plus complexe. Il génère des erreurs lorsque vous lancez quelques cas (tests unitaires) et vous déboguez dans le code et tracez. Vous examinez les valeurs au fur et à mesure et décidez si elles ont raison ou tort. Ceci est un test unitaire dans une certaine mesure.

Les tests unitaires prennent vraiment ce comportement, le formalisent en un modèle structuré et le sauvegardent pour que vous puissiez facilement relancer ces tests. Si vous écrivez un scénario de test unitaire “correct” plutôt que de le tester manuellement, cela prend le même temps, ou peut-être moins lorsque vous en avez l’expérience, et vous pouvez le répéter à plusieurs resockets

Pendant des années, j’ai essayé de convaincre les gens qu’ils devaient écrire un test unitaire pour leur code. Qu’ils aient d’abord écrit les tests (comme dans TDD) ou après avoir codé les fonctionnalités, j’ai toujours essayé de leur expliquer tous les avantages des tests unitaires pour le code. Presque personne n’était en désaccord avec moi. Vous ne pouvez pas être en désaccord avec quelque chose qui est évident, et toute personne intelligente verra les avantages du test unitaire et du TDD.

Le problème avec les tests unitaires est que cela nécessite un changement de comportement, et il est très difficile de changer le comportement des gens. Avec les mots, beaucoup de gens seront d’accord avec vous, mais vous ne verrez pas beaucoup de changements dans leur façon de faire.

Vous devez convaincre les gens en faisant. Votre réussite personnelle attirera plus de personnes que tous les arguments que vous pourriez avoir. S’ils voient que vous ne parlez pas seulement du test unitaire ou du 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 de premier plan car personne n’écrit le test unitaire du premier coup, vous devrez donc peut-être les guider sur la manière de le faire, leur montrer le chemin et les outils à leur disposition. Aidez-les pendant qu’ils écrivent leurs premiers tests, examinez les tests qu’ils écrivent d’eux-mêmes et montrez-leur les astuces, les idiomes et les modèles que vous avez appris grâce à vos propres expériences. Après un certain temps, ils commenceront à voir les avantages par eux-mêmes et ils changeront de comportement pour incorporer des tests unitaires ou TDD dans leur boîte à outils.

Les changements ne se produiront pas la nuit, mais avec un peu de patience, vous pouvez atteindre votre objective.

La majeure partie du développement piloté par les tests, souvent passé sous silence, consiste à écrire du code testable. Cela semble être une sorte de compromis au début, mais vous découvrirez que le code testable est également modulaire, maintenable et lisible. Si vous avez toujours besoin d’aide pour convaincre les gens, voici une présentation simple sur les avantages des tests unitaires.

Si votre base de code existante ne se prête pas aux tests unitaires et qu’elle est déjà en production, vous risquez de créer plus de problèmes que vous ne le faites en essayant de refactoriser tout votre code pour qu’il soit testable par unité.

Vous feriez peut-être mieux de vous efforcer d’améliorer vos tests d’intégration. Il y a beaucoup de code qui est plus simple à écrire sans test unitaire, et si un QA peut valider la fonctionnalité par rapport à un document d’exigences, alors vous avez terminé. Expédier.

L’exemple classique de ceci est un SqlDataReader intégré 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. Qu’est-ce que vous testez à l’unité? Si la page fait ce qu’elle est censée faire, devriez-vous la redéfinir en plusieurs couches afin de pouvoir automatiser quelque chose?

L’une des meilleures choses à propos des tests unitaires est que votre code sera plus facile à tester que vous le faites. Un code préexistant créé sans test est toujours un défi, car comme ils n’étaient pas conçus pour être testés par unité, il n’est pas rare de disposer d’un niveau élevé de couplage entre les classes, les objects difficiles à configurer dans votre classe – comme un courrier électronique envoi de référence de service – et ainsi de suite. Mais ne vous laissez pas abattre! Vous constaterez que votre conception de code globale s’améliorera au fur et à mesure que vous commencerez à écrire des tests unitaires, et plus vous testerez, plus vous aurez confiance en votre capacité à modifier votre application sans craindre de vous casser .

Il existe plusieurs raisons pour tester votre code en unités, mais au fil du temps, vous découvrirez 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 faire des tests unitaires automatisés malgré les affirmations selon lesquelles je passerais beaucoup plus de temps à faire les tests que si je testais le système manuellement. Avec tous mes tests unitaires effectués, je lance plus de 400 tests en moins de 10 minutes, et chaque fois que je faisais un petit changement dans le code, il ne me fallait que dix codes pour que le code fonctionne toujours. minutes. Pouvez-vous imaginer le temps que l’on passerait à exécuter ces 400 + tests à la main?

En ce qui concerne les tests automatisés – que ce soit des tests unitaires ou des tests d’acceptation – tout le monde pense que coder ce que vous pouvez faire manuellement est parfois inutile – 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 sont déjà payés.

Un dernier conseil serait de ne pas seulement tester votre code, mais de commencer par faire le test (voir TDD et BDD pour plus d’informations).

Les tests unitaires sont également particulièrement utiles pour la refactorisation ou la réécriture d’un code. Si vous avez une bonne couverture de tests unitaires, vous pouvez refactoriser en toute confiance. Sans les tests unitaires, il est souvent difficile de s’assurer que vous n’avez rien cassé.

En bref – oui. Ils valent chaque once d’effort… jusqu’à un certain point. En fin de compte, les tests sont toujours du code et, tout comme la croissance du code, vos tests devront éventuellement être refaits pour être maintenables et durables. Il y a une tonne de GOTCHAS! En ce qui concerne les tests unitaires, mais l’homme, l’homme, l’homme, rien, et je veux dire, ne permet à un développeur de faire des changements avec plus de confiance qu’un riche ensemble de tests unitaires.

Je travaille actuellement sur un projet … c’est un peu TDD, et nous avons la plupart de nos règles métier encapsulées en tant que tests … nous avons environ 500 tests unitaires en ce moment. Cette itération passée, j’ai dû réorganiser notre source de données et comment notre application de bureau s’interface avec cette source de données. Il m’a fallu deux jours, tout le temps je continuais à courir des tests unitaires pour voir ce que j’avais cassé et réparé. Faire un changement; Construisez et exécutez vos tests; répare ce que tu as cassé. Laver, rincer, répéter si nécessaire. Ce qui aurait traditionnellement pris des jours de QA et de charges de bateaux était plutôt une expérience courte et agréable.

Préparez-vous à l’avance, un peu d’effort supplémentaire, et cela vous rapporte 10 fois plus tard lorsque vous devez commencer à vous débrouiller avec les fonctionnalités / fonctionnalités de base.

J’ai acheté ce livre – c’est une bible de connaissances sur xUnit Testing – c’est probablement l’un des livres les plus référencés sur mon étagère, et je le consulte quotidiennement: texte du lien

De temps en temps, l’un de mes collègues ou moi-même passons quelques heures à trouver le bogue légèrement obscur et une fois que la cause du bogue est trouvée 90% du temps, le code n’est pas testé par unité. Le test unitaire n’existe pas car le dev coupe les coins pour gagner du temps, mais perd ce débogage.

Prendre le peu de temps pour écrire un test unitaire peut permettre de gagner des heures de débogage futur.

Je travaille comme ingénieur de maintenance sur une base de code mal documentée, horrible et volumineuse. Je souhaite que les personnes qui ont écrit le code aient écrit les tests unitaires pour cela.
Chaque fois que je fais un changement et que je mets à jour le code de production, j’ai peur d’introduire un bogue pour ne pas avoir considéré certaines conditions.
S’ils écrivaient le test, apporter des modifications à la base de code serait plus facile et plus rapide (en même temps, la base de code serait dans un meilleur état).

Je pense que les tests unitaires sont 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 originaux.

Les tests unitaires valent vraiment la peine. Malheureusement, vous avez choisi un scénario difficile (mais malheureusement commun) pour le mettre en œuvre.

Le meilleur avantage des tests unitaires que vous obtiendrez lors de l’utilisation à partir de rien – sur quelques petits projets sélectionnés, j’ai eu la chance d’écrire mes tests unitaires avant d’implémenter mes classes (l’interface était déjà complète à ce moment-là). point). Avec des tests unitaires appropriés, vous trouverez et corrigerez les bogues dans vos classes pendant leur enfance, et ce, peu importe le système complexe dans lequel ils seront sans aucun doute intégrés ultérieurement.

Si votre logiciel est résolument orienté object, vous devriez pouvoir append des tests unitaires au niveau de la classe sans trop d’effort. Si vous n’êtes pas chanceux, vous devriez quand même essayer d’intégrer les tests unitaires partout où vous le pouvez. Lorsque vous ajoutez de nouvelles fonctionnalités, assurez-vous que les nouvelles pièces sont bien définies avec des interfaces claires et que vous trouverez que les tests unitaires vous simplifient la vie.

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 rendre le code 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 test unitaire, 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.

J’ai écrit un très gros article sur le sujet. J’ai trouvé que les tests unitaires ne valent pas le coup et sont généralement réduits lorsque les délais se rapprochent.

Au lieu de parler des tests unitaires du sharepoint vue de la vérification “après test”, nous devrions examiner la vraie valeur trouvée lorsque vous avez décidé d’écrire une spéc / test / idée avant l’implémentation.

Cette idée simple a changé la façon dont j’écris les logiciels et je ne reviendrais pas à l’ancienne façon.

Comment le premier développement test a changé ma vie

Oui – Les tests unitaires en valent vraiment la peine, mais vous devez savoir que ce n’est pas une solution miracle. Le test unitaire est un travail et vous devrez travailler pour que le test rest à jour et pertinent au fur et à mesure que le code change, mais la valeur offerte en vaut la peine. La possibilité de refacturer en toute impunité est un avantage considérable. en exécutant vos tests après tout changement de code. L’astuce consiste à ne pas trop s’attarder sur l’unité de travail que vous testez ou sur la manière dont vous testez les exigences du test et quand un test unitaire est réellement un test fonctionnel, etc. En fin de compte, la réalité est que tout test que vous faites en tant que 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énuées de sens car les autres ne testent pas vraiment quelque chose d’utile ou de spécifique au domaine comme les règles métier, etc. 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 les fonctionnalités essentielles du code pour lequel il était écrit et expliquaient comment utiliser le code.

Un de mes trucs préférés lors de l’exploration de nouveaux frameworks ou bases de code est d’écrire des tests unitaires pour «comprendre» comment fonctionnent les choses. C’est un excellent moyen d’en apprendre plus sur quelque chose de nouveau au lieu de lire un doc sec 🙂

J’ai récemment vécu 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 qu’ils devaient leur être spécifiquement vendus, alors voici les points que j’ai utilisés (avec succès):

• Ils gagnent du temps lors de l’exécution de tests négatifs, où vous gérez des entrées inattendues (pointeurs nuls, valeurs hors limites, etc.), comme vous pouvez le faire dans 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 lorsque quelqu’un entre et modifie le code sans une compréhension complète, il peut détecter de nombreuses erreurs stupides.

J’ai découvert TDD il y a quelques années et j’ai depuis écrit tous mes projets pour animaux de compagnie. J’ai estimé qu’il fallait à peu près le même temps pour mettre en place un projet TDD que pour le faire avec des cowboys ensemble, mais j’ai tellement confiance dans le produit final que je ne peux m’empêcher de ressentir un sentiment de réussite.

Je pense également que cela améliore mon style de conception (beaucoup plus orienté vers l’interface au cas où j’aurais besoin de me moquer de choses ensemble) et, comme l’écrit le message vert en haut, cela aide à «coder la constipation»: pour écrire ensuite, ou vous avez une tâche ardue devant vous, vous pouvez écrire petit.

Enfin, je trouve que l’application de loin la plus utile de TDD réside dans le débogage, ne serait-ce que parce que vous avez déjà développé un cadre d’interrogation avec lequel vous pouvez pousser le projet à produire le bogue de manière reproductible.

Une chose dont personne n’a encore parlé est l’engagement de tous les développeurs à exécuter et à mettre à jour les tests automatisés existants. Les tests automatisés auxquels vous revenez et que vous découvrez en raison de nouveaux développements perdent beaucoup de valeur et rendent les tests automatisés vraiment pénibles. La plupart de ces tests n’indiqueront pas de bogues, car le développeur a testé le code manuellement, de sorte que le temps passé à les mettre à jour n’est que du gaspillage.

Il est beaucoup plus important de convaincre les sceptiques de ne pas détruire le travail que les autres font sur les tests unitaires pour obtenir de la valeur des tests.

Passer des heures à mettre à jour les tests qui ont échoué à cause de nouvelles fonctionnalités à chaque mise à jour depuis le référentiel n’est ni productif ni amusant.

Si vous utilisez NUnit, une démonstration simple mais efficace consiste à exécuter les propres suites de tests de NUnit devant elles. En voyant une véritable suite de tests donnant une base de code, une séance d’entraînement vaut mille mots …

Les tests unitaires aident beaucoup dans les projets qui sont plus importants que ceux qu’un développeur peut avoir en tête. Ils vous permettent d’exécuter la suite de tests unitaires avant de vérifier et de découvrir si vous avez cassé quelque chose. Cela réduit énormément le fait de devoir s’asseoir et se tourner les pouces en attendant que quelqu’un d’autre répare un bug qu’ils ont enregistré, ou de se résoudre à revenir sur leurs modifications pour que vous puissiez travailler. Il est également extrêmement utile pour le refactoring, vous pouvez donc être sûr que le code refactoré passe tous les tests effectués par le code d’origine.

Avec la suite de tests unitaire, vous pouvez apporter des modifications au code tout en laissant le rest des fonctionnalités intactes. C’est un grand avantage. Utilisez-vous la suite de tests unitaires et de test de régression lorsque vous avez fini de coder une nouvelle fonctionnalité?

Je suis d’accord avec le sharepoint vue opposé à la majorité ici: Il est correct de ne pas écrire les tests unitaires La programmation particulièrement lourde (IA par exemple) est difficile à combiner avec les tests unitaires.