Les tests unitaires valent-ils l'effort? [fermé]

Je travaille à 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 spécifique, nous ajouterions des tests unitaires à mesure que nous ajouterons des fonctionnalités ou des bogues corrigés. Malheureusement, notre base de code ne se prête pas à des tests faciles.

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

"Mec, j'adore les tests unitaires, j'ai juste pu apporter un tas de changements à la façon dont quelque chose fonctionne, puis j'ai pu confirmer que je n'avais rien cassé en refaisant le test ..."

Les détails changent quotidiennement, mais le sentiment ne change pas. Les tests unitaires et le développement piloté par les tests (TDD) ont tellement d'avantages cachés et personnels ainsi que les avantages évidents que vous ne pouvez vraiment pas expliquer à quelqu'un jusqu'à ce qu'il le fasse lui-même.

Mais, ignorant cela, voici ma tentative!

1. Les tests unitaires vous permettent d'apporter rapidement de grandes modifications au code. Vous savez que cela fonctionne maintenant parce que vous avez exécuté les tests, lorsque vous apportez les modifications que vous devez apporter, vous devez faire fonctionner les tests à nouveau. Cela fait gagner des heures.

2. TDD vous aide à savoir quand arrêter le codage. Vos tests vous donnent l'assurance que vous en avez assez fait pour le moment et que vous pouvez arrêter de peaufiner et passer à la chose suivante.

3. Les tests et le code fonctionnent ensemble pour obtenir un meilleur code. Votre code pourrait être incorrect / bogué. Votre TEST pourrait être mauvais / bogué. Dans TDD, vous misez sur les chances que les deux soient mauvais / buggés. Souvent, c'est le test qui doit être corrigé, mais c'est toujours un bon résultat.

4. TDD aide à coder la constipation. Lorsque vous êtes confronté à un travail important et intimidant avant de rédiger les tests, vous pourrez vous déplacer rapidement.

5. 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.

6. 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 là où vous vous étiez arrêté après une interruption, car vous pouvez voir où vous êtes arrivé - ce prochain feu rouge qui doit être réparé.

7. Contrairement aux tests de croyances populaires, cela ne signifie pas écrire deux fois plus de code ou coder plus lentement. C'est plus rapide et plus robuste que le codage sans tests une fois que vous avez compris. Le code de test lui-même est généralement relativement trivial et n'ajoute pas de gros frais généraux à ce que vous faites. C'est celui que vous ne croirez qu'en le faisant :)

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 cela 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 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. Ajustez le code jusqu'à ce que les tests s'exécutent à nouveau.

Beaucoup de travail auquel je suis impliqué ne fait pas bien le test unitaire (interactions avec les utilisateurs d'applications Web, etc.), mais même ainsi, nous sommes tous testés infectés dans cette boutique, et plus heureux lorsque nos tests sont liés. Je ne peux pas recommander assez l'approche.

Les tests unitaires, c'est un peu 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 sûr de vraiment gagner autre chose que des jambes et des bras douloureux.

Puis, après peut-être une ou deux semaines, juste au moment où la douleur disparaît, une grande échéance commence à approcher. Vous devez passer chaque heure d'éveil à essayer de faire un travail "utile", donc vous éliminez les choses étrangères, comme aller au gymnase. Vous perdez l'habitude, et lorsque Big Deadline est terminé, vous êtes de retour à la case départ. Si vous parvenez à retourner au gymnase, vous vous sentez tout aussi douloureux que la première fois que vous y êtes allé.

Vous faites un peu de lecture pour voir si vous faites quelque chose de mal. Vous commencez à ressentir un peu de méchanceté irrationnelle envers tous les gens en forme et heureux vantant les vertus de l'exercice. Vous vous rendez compte que vous n'avez pas grand-chose en commun. Ils n'ont pas à conduire 15 minutes pour aller au gymnase; il y en a un dans leur immeuble. Ils n'ont à discuter avec personne 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 plus nécessaire que votre patron ne vous demanderait d'arrêter de manger.

Donc, pour répondre à votre question, les tests unitaires valent généralement l'effort, mais la quantité d'effort requise ne sera pas la même pour tout le monde. Les tests unitaires peuvent nécessiter énormément d'efforts si vous traitez avec une base de code spaghetti dans une entreprise qui ne valorise pas réellement la qualité du code. (Beaucoup de gestionnaires chanteront les louanges de Unit Testing, mais cela ne signifie pas qu'ils s'y tiendront quand cela sera important.)

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 amené à vous attendre, ne vous en voulez pas. Vous devrez peut-être trouver un nouvel emploi pour que les tests unitaires fonctionnent vraiment pour vous.

Le meilleur moyen de convaincre ... trouver un bug, écrire un test unitaire pour lui, corriger le bug.

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

Si vous le faites suffisamment, les autres se rattraperont rapidement.

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 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 argumentation et de l'aborder 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 vous tenir debout). Qui sait? Peut-être qu'ils vous convaincront pourquoi les tests unitaires ne conviennent pas à votre situation. Peu probable, mais possible. Peut-être que si vous postez leurs arguments contre les 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 les tests unitaires avec trop de zèle sans tenir compte des préoccupations des gens, 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 qu'il y paraît - cela nécessite généralement un certain temps et des mesures minutieuses pour élaborer un argument convaincant.

Les tests unitaires sont un outil, comme tout autre, et doivent être appliqués de telle manière que les avantages (capture de bugs) l'emportent sur les coûts (l'effort de les écrire). Ne les utilisez pas si / où elles n'ont pas de sens et rappelez-vous qu'elles 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, c'est ceci:

1. Ils peuvent sauter la rédaction d'un test pour une méthode s'ils ont un bon argument pourquoi elle 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 autrement vérifiée (par exemple, inspection, assertions , 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é, puis doivent ê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 (écrits une fois et exécutés à plusieurs reprises par la suite. ). Parfois, je suis d'accord avec eux, mais le plus souvent, je vais débattre de savoir si une méthode est vraiment trop simple ou trop difficile à tester.

   • Si un développeur soutient 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 s'exécuteront tous les soirs (vous effectuez des builds tous les soirs, non?) Pour l'année prochaine ou plus et en vaut la peine si même une seule fois il arrive à attraper un problème qui peut avoir pris 15 minutes ou plus à identifier et déboguer. En outre, l'écriture des tests unitaires faciles augmente le nombre de tests unitaires, ce qui donne au développeur une belle apparence.

   • D'un autre côté, si un développeur soutient qu'une méthode semble trop difficile à tester unitaire (ne vaut pas l'effort important 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 des singletons, l'heure actuelle ou des ressources externes comme 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 obtient la ressource (par exemple, appelle getTime ()) et une méthode qui prend la ressource en argument (par exemple, prend l'horodatage en paramètre). Je les laisse sauter le test de la méthode qui récupère la ressource et ils écrivent à 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 façon dont leurs tests unitaires devraient être complets. Plus tard dans le développement, chaque fois que nous trouvons un bogue, ils devraient déterminer si des tests unitaires plus complets auraient résolu le problème. Si tel est le cas et si de tels bogues surviennent à plusieurs reprises, ils doivent déplacer la "ligne" vers l'écriture de tests unitaires plus complets à l'avenir (en commençant par l'ajout ou l'extension du test unitaire pour le 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 existe trop de tests unitaires. Sur mon lieu de travail, chaque fois que nous faisons des leçons apprises, j'entends inévitablement "nous devons passer plus de tests unitaires". La direction hoche la tête en accord parce que ça leur a cogné la tête que "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 devrait être le code de test unitaire par rapport au code de production. Un lieu 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 boguées) (pensez à MS Word). D'un autre côté, une boutique stricte 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 des rapports sur le crash de ce dernier produit, mais cela a probablement autant à voir avec le produit qui ne se vend pas très bien qu'avec la qualité du code.

Pire encore, la seule certitude du développement logiciel est peut-être que "le changement est inévitable". Supposons que la boutique stricte (90% de tests unitaires / 10% de code de production) crée un produit qui a exactement 2 fonctionnalités (en supposant que 5% du code de production == 1 fonctionnalité). Si le client arrive et modifie 1 des fonctionnalités, ce changement supprime 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 de code est mise à la poubelle (~ 25% = ~ 4,4% de tests unitaires + 20% du code de production).

Mon point 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 du problème. Si vous pouvez convaincre vos pairs et / ou votre gestion de cela, vous gagnez en crédibilité et avez peut-être plus de chances de les gagner.

J'ai joué avec les tests unitaires à plusieurs reprises et je suis toujours convaincu que cela 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. Lorsque j'ai essayé de "simuler" la base de données à des fins de tests unitaires, elle est devenue très désordonnée et semblait un peu inutile.

Lorsque j'ai écrit des tests unitaires sur 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 quels domaines de code peuvent être affectés par quelque chose sur lequel je travaille, et je teste ces domaines manuellement. Je veux proposer 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 les parcoure moi-même, 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 dans ce cas, je pense que si les développeurs sont de haute qualité, une bonne communication et un code bien écrit devraient souvent suffire. .

Une grande chose au sujet des tests unitaires est qu'ils servent de documentation sur la façon 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 au 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 peur d'apporter des modifications au code (rien de tel que la lueur chaleureuse de voir le code fonctionner ou exploser à chaque fois qu'un changement est effectué)
• 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 les frais généraux de création de tests. Il n'est pas difficile de créer des extraits qui permettent la création d'un plan de classe et d'un appareil de test unitaire associé en quelques secondes.

Vous devriez tester le moins possible!

ce qui signifie que vous devez écrire juste assez de tests unitaires pour révéler l'intention. Cela passe souvent 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 se casseront jamais, sont gros et maladroits et n'offrent pas beaucoup de valeur, ils finissent par vous ralentir.

Je n'ai vu cela dans aucune des autres réponses, mais j'ai remarqué une chose: je pouvais déboguer beaucoup plus rapidement . Vous n'avez pas besoin d'explorer votre application avec juste la bonne séquence d'étapes pour obtenir le code de votre correction, seulement pour découvrir 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.

[J'ai une remarque à faire que je ne peux pas voir ci-dessus]

"Tout le monde fait des tests unitaires, ils ne le réalisent pas nécessairement - FAIT"

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

Il s'agit de tests unitaires - basiques et mal assemblés, mais vous testez le morceau de 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 que vous déboguez dans le code et que vous tracez cependant. Vous examinez les valeurs au fur et à mesure et décidez si elles sont bonnes ou mauvaises. Il s'agit dans une certaine mesure de tests unitaires.

Les tests unitaires ici prennent vraiment ce comportement, le formalisent en un modèle structuré et l'enregistrent afin que vous puissiez facilement réexécuter ces tests. Si vous écrivez un cas de test unitaire "approprié" plutôt que de le tester manuellement, cela prend le même temps, ou peut-être moins que vous en avez l'habitude, et vous pouvez 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 d'avoir 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 d'évident, et toute personne intelligente verra les avantages du test unitaire et du TDD.

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

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 de tests unitaires ou TDD, mais que vous faites ce que vous prêchez et que vous réussissez, les gens essaieront de vous imiter.

Vous devez également assumer un rôle principal, car personne n'écrit le test unitaire correctement la première fois, vous devrez donc peut-être les guider sur la façon de 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 par eux-mêmes et montrez-leur les astuces, les idiomes et les schémas 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 changeront leur comportement pour incorporer des tests unitaires ou TDD dans leur boîte à outils.

Les changements ne se produiront pas pendant la nuit, mais avec un peu de patience, vous pourrez atteindre votre objectif.

Une partie importante du développement piloté par les tests qui est souvent ignorée est l'écriture de code testable. Cela ressemble à une sorte de compromis au début, mais vous découvrirez que le code testable est également finalement modulaire, maintenable et lisible. Si vous avez besoin d' aide à convaincre les gens c'est une présentation simple et agréable 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 pouvez créer plus de problèmes que vous n'en résolvez en essayant de refactoriser tout votre code afin qu'il soit testable unitaire.

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

L'exemple classique de cela dans mon esprit est un SqlDataReader intégré dans une page ASPX liée à une GridView. Le code est tout dans le fichier ASPX. Le SQL est dans une procédure stockée. Que testez-vous unitaire? Si la page fait ce qu'elle est censée faire, devriez-vous vraiment la repenser en plusieurs couches afin d'avoir quelque chose à automatiser?

L'une des meilleures choses à propos des tests unitaires est que votre code deviendra plus facile à tester au fur et à mesure. Le code préexistant créé sans tests est toujours un défi car comme ils n'étaient pas destinés à être testés à l'unité, il n'est pas rare d'avoir un haut niveau de couplage entre les classes, des objets difficiles à configurer à l'intérieur de votre classe - comme un e-mail envoi de référence de service - et ainsi de suite. Mais ne vous laissez pas 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 serez confiant en lui apportant encore plus de modifications sans craindre de casser votre application ou d'introduire des bogues. .

Il y a plusieurs raisons de tester votre code à l'unité, 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 je ne le ferais en testant le système manuellement. Avec tous mes tests unitaires effectués, j'ai exécuté plus de 400 cas de test en moins de 10 minutes, et chaque fois que je devais faire un petit changement dans le code, tout ce qu'il me fallait pour être sûr que le code fonctionnait toujours sans bugs était de dix minutes. Pouvez-vous imaginer le temps que l'on passerait à exécuter manuellement plus de 400 cas de test?

En ce qui concerne les tests automatisés - que ce soit les tests unitaires ou les tests d'acceptation - tout le monde pense que c'est un effort inutile de coder ce que vous pouvez faire manuellement, et parfois c'est 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 gaspillés sont déjà payés.

Un dernier conseil serait non seulement de tester votre code à l'unité, mais de commencer par faire le test en premier (voir TDD et BDD pour plus)

Les tests unitaires sont également particulièrement utiles lorsqu'il s'agit de refactoriser ou de réécrire un morceau de code. Si vous avez une bonne couverture des tests unitaires, vous pouvez refactoriser en toute confiance. Sans 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. Les tests sont, en fin de compte, toujours du code, et tout comme la croissance de code typique, vos tests devront éventuellement être refactorisés afin d'être maintenables et durables. Il y a une tonne de GOTCHAS! quand il s'agit de 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 riche ensemble 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 en ce moment. Cette dernière itération, j'ai dû réorganiser notre source de données et la façon dont notre application de bureau s'interface avec cette source de données. Cela m'a pris quelques jours, tout le temps j'ai continué à faire des tests unitaires pour voir ce que je cassais et le réparer. Faire un changement; Créez et exécutez vos tests; réparez ce que vous avez cassé. Laver, rincer, répéter au besoin. Ce qui aurait traditionnellement pris des jours d'AQ et de charges de stress sur les bateaux a plutôt été une expérience courte et agréable.

Préparez-vous à l'avance, un peu d'effort supplémentaire, et cela paiera 10 fois plus tard lorsque vous devrez commencer à vous promener avec les principales fonctionnalités / fonctionnalités.

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

Parfois, moi-même ou l'un de mes collègues passons quelques heures à résoudre le bug légèrement obscur et une fois que la cause du bug est trouvée, 90% du temps, le code n'est pas testé à l'unité. Le test unitaire n'existe pas parce que le développeur coupe les coins pour gagner du temps, mais perd ensuite cela et plus de débogage.

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

Je travaille en tant qu'ingénieur de maintenance d'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 de pouvoir introduire un bug pour ne pas avoir considéré une condition.
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 s'avèrent très utiles lors de l'écriture d'api ou de frameworks qui doivent durer de nombreuses années et être utilisés / modifiés / évolués par des personnes autres que les codeurs d'origine.

Les tests unitaires en valent vraiment la peine. Malheureusement, vous avez choisi un scénario difficile (mais malheureusement courant) dans lequel l'implémenter.

Le meilleur avantage des tests unitaires que vous obtiendrez sera de les utiliser dès le départ - 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 stade). point). Avec des tests unitaires appropriés, vous trouverez et corrigerez des bogues dans vos classes alors qu'elles sont encore à leurs balbutiements et pas n'importe où près du système complexe dans lequel elles seront sans aucun doute intégrées à l'avenir.

Si votre logiciel est solidement orienté objet, vous devriez pouvoir ajouter des tests unitaires au niveau de la classe sans trop d'effort. Si vous n'êtes pas aussi chanceux, vous devriez toujours 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.

Quand vous avez dit, "notre base de code ne se prête pas à des tests faciles" est le premier signe d'une odeur de code. L'écriture de 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 j'ai dû é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 fait des tests unitaires, mais Bill Gates a donné un écran bleu lors de sa présentation.

J'ai écrit un très gros article de blog sur le sujet. J'ai trouvé que les tests unitaires ne valent pas à eux seuls le travail et sont généralement réduits lorsque les délais se rapprochent.

Au lieu de parler de tests unitaires du point de vue de la vérification «après test», nous devrions examiner la vraie valeur trouvée lorsque vous vous apprêtez à écrire une spécification / test / idée avant la mise en œuvre.

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

Comment le premier développement du 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 maintenir le test à jour et pertinent à mesure que le code change, mais la valeur offerte vaut l'effort que vous devez y consacrer. La possibilité de refactoriser en toute impunité est un énorme avantage car vous pouvez toujours valider la fonctionnalité en exécutant vos tests après tout changement de code. L'astuce est de ne pas trop vous accrocher exactement à l'unité de travail que vous testez ou à la façon dont vous échafaudez les exigences du test et quand un test unitaire est vraiment un test fonctionnel, etc. Les gens discuteront de ce genre de choses pendant des heures à la fin et la réalité est que tout test que vous faites comme votre code d'écriture vaut mieux que de ne pas le faire. L'autre axiome concerne la qualité et non la quantité - j'ai vu des bases de code avec 1000 ' s de test qui sont essentiellement dénués de sens car le reste ne teste pas vraiment quoi que ce soit d'utile ou quoi que ce soit de spécifique au domaine comme les règles métier, etc. du domaine particulier. 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 ont testé la fonctionnalité de base du code pour lequel il a été écrit et ont exprimé comment le code devrait être utilisé.

L'une de mes astuces préférées lorsque j'explore de nouveaux frameworks ou bases de code est d'écrire des tests unitaires pour «it» afin de découvrir comment les choses fonctionnent. C'est un excellent moyen d'en savoir plus sur quelque chose de nouveau au lieu de lire un doc sec :)

J'ai récemment vécu exactement la même expérience sur mon lieu de travail et j'ai découvert que la plupart d'entre eux connaissaient les avantages théoriques mais devaient être vendus en fonction des avantages spécifiques pour eux, alors voici les points que j'ai utilisés (avec succès):

• Ils permettent de gagner du temps lors des tests négatifs, où vous gérez des entrées inattendues (pointeurs nuls, valeurs hors limites, etc.), car vous pouvez faire tout cela 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 pendant l'exécution normale.

et le grand ...

• Vous n'avez peut-être pas besoin de tests unitaires, mais lorsque quelqu'un d'autre entre et modifie le code sans une compréhension complète, il peut attraper beaucoup d'erreurs stupides qu'ils pourraient faire.

J'ai découvert TDD il y a quelques années et j'ai depuis écrit tous mes projets pour animaux de compagnie en l'utilisant. J'ai estimé qu'il faut à peu près autant de temps pour TDD qu'un projet que pour le cowboy ensemble, mais j'ai une telle confiance accrue dans le produit final que je ne peux pas empêcher un sentiment d'accomplissement.

Je pense également que cela améliore mon style de conception (beaucoup plus orienté interface au cas où je devrais me moquer des choses ensemble) et, comme l'écrit le post vert en haut, il aide à la "constipation de codage": quand vous ne savez pas quoi pour écrire ensuite, ou si vous avez une tâche intimidante devant vous, vous pouvez écrire petit.

Enfin, je trouve que l'application de loin la plus utile de TDD est 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.

Personne n'a encore mentionné l'obtention de l'engagement de tous les développeurs à réellement exécuter et mettre à jour tout test automatisé existant. Les tests automatisés auxquels vous revenez et que vous trouvez défectueux à cause d'un nouveau développement perd beaucoup de valeur et rendent les tests automatisés vraiment pénibles. La plupart de ces tests n'indiqueront pas de bogues puisque le développeur a testé le code manuellement, donc le temps passé à les mettre à jour n'est que du gaspillage.

Convaincre les sceptiques de ne pas détruire le travail que font les autres sur les tests unitaires est beaucoup plus important pour obtenir de la valeur des tests et pourrait être plus facile.

Passer des heures à mettre à jour des tests qui ont échoué en raison de nouvelles fonctionnalités chaque fois que vous mettez à jour à partir du 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. Voir une vraie suite de tests donner à une base de code un entraînement vaut mille mots ...

Les tests unitaires aident beaucoup dans les projets qui sont plus grands que n'importe quel développeur peut avoir dans leur 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 beaucoup les cas où vous devez vous asseoir et tourner les pouces en attendant que quelqu'un d'autre corrige un bogue qu'il a enregistré, ou qui se donne la peine de revenir sur sa modification afin que vous puissiez faire du travail. Il est également extrêmement précieux 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 unitaires, on peut apporter des modifications au code tout en laissant le reste des fonctionnalités intactes. C'est un grand avantage. Utilisez-vous des tests unitaires et une suite de tests de régression lorsque vous avez fini de coder une nouvelle fonctionnalité.

Je suis d'accord avec le point de vue opposé à la majorité ici: c'est OK de ne pas écrire de tests unitaires La programmation particulièrement lourde de prototypes (AI par exemple) est difficile à combiner avec les tests unitaires.