Les tests unitaires sont-ils vraiment si utiles?
Je viens d'obtenir mon diplôme en CS et j'ai actuellement un emploi en tant que développeur junior .NET (C #, ASP.NET et formulaires Web). À l'époque où j'étais encore à l'université, le sujet des tests unitaires a été abordé, mais je n'en ai jamais vraiment vu les avantages. Je comprends ce qu'il est censé faire, à savoir déterminer si un bloc de code est apte à être utilisé ou non. Cependant, je n'ai jamais eu à passer de test unitaire auparavant, et je n'en ai jamais ressenti le besoin.
Comme je l'ai déjà mentionné, je développe généralement avec des formulaires Web ASP.NET et récemment, j'ai pensé à écrire des tests unitaires. Mais j'ai quelques questions à ce sujet.
J'ai lu que les tests unitaires se produisent souvent en écrivant des "simulacres". Bien que je comprenne ce concept, je n'arrive pas à comprendre comment je suis censé écrire des simulations pour des sites Web qui sont complètement dynamiques, et où presque tout dépend des données provenant d'une base de données. Par exemple: j'utilise beaucoup de répéteurs qui ont des événements ItemDataBound etc. (encore une fois en fonction de données "inconnues").
Donc, question numéro 1: l'écriture de tests unitaires pour les formulaires Web ASP.NET est-elle souvent effectuée, et si c'est le cas: comment résoudre le problème de "l'environnement dynamique"?
Quand je développe, je passe par beaucoup d'essais et d'erreurs. Cela ne signifie pas que je ne sais pas ce que je fais, mais je veux dire que j'écris habituellement du code, Ctrl F5 et voyez ce qui se passe. Bien que cette approche fasse le travail la plupart du temps, j'ai parfois l'impression que je suis un peu désemparé (à cause de ma petite expérience). Je perds parfois aussi beaucoup de temps comme ça.
Donc, question numéro 2: Voulez-vous me conseiller de commencer à écrire des tests unitaires? Je pense que cela pourrait m'aider dans la mise en œuvre réelle, mais là encore, j'ai l'impression que cela pourrait me ralentir.
À mon avis: oui, ils le sont, et oui, vous devriez.
Ils vous donnent confiance dans les changements que vous apportez (tout le reste fonctionne toujours). Cette confiance est ce dont vous avez besoin pour modeler le code, sinon vous pourriez avoir peur de changer les choses.
Ils améliorent votre code; la plupart des erreurs simples sont détectées tôt avec les tests unitaires. Détecter les bogues tôt et les corriger est toujours moins cher que de les corriger plus tard, par exemple lorsque l'application est en production.
Ils servent de documentation aux autres développeurs sur le fonctionnement et l'utilisation de votre code.
Le premier problème auquel vous êtes confronté est que ASP.NET en soi ne vous aide pas à écrire des tests unitaires - en fait, cela fonctionne contre vous. Si vous avez le choix, commencez à utiliser ASP.NET MVC , qui a été créé en pensant aux tests unitaires. Si vous ne pouvez pas utiliser ASP.NET MVC, vous devez utiliser le modèle MVP dans ASP.NET afin qu'au moins vous puissiez tester facilement votre logique.
En plus de cela, il vous suffit de maîtriser la rédaction de tests unitaires. Si vous pratiquez TDD, votre code est créé testable - en d'autres termes, Nice et propre.
Je vous conseillerais de pratiquer et de jumeler le programme. En lisant:
- Développement de logiciels agiles, principes, modèles et pratiques [Relié]
- Modèles de conception Head First
- Bible de modèle de conception GOF
- première introduction de Roy osherove aux tests unitaires
- bible des modèles de tests unitaires
Ou, pour un premier aperçu:
Non.
Le concept derrière les tests unitaires est basé sur une prémisse qui était connue comme fausse avant même que les tests unitaires ne soient inventés: l'idée que les tests peuvent prouver que votre code est correct.
Avoir beaucoup de tests qui réussissent tous prouve une chose et une seule chose: que vous avez beaucoup de tests qui réussissent tous. Cela ne prouve pas que ce que les tests testent correspond à la spécification. Cela ne prouve pas que votre code est exempt d'erreurs que vous n'aviez jamais envisagées lorsque vous avez écrit les tests. (Et les choses que vous pensiez tester étaient les problèmes possibles sur lesquels vous vous concentriez, donc vous avez probablement réussi à les corriger de toute façon!) Et enfin et surtout, cela ne prouve pas que les tests, qui sont eux-mêmes du code, sont exempts de bogues. (Suivez ce dernier jusqu'à sa conclusion logique et vous vous retrouvez avec tortues tout le long .)
Djikstra saccagé le concept de tests-comme-preuve-de-correction en 1988, et ce qu'il a écrit reste tout aussi valable aujourd'hui:
Cela fait maintenant deux décennies qu'il a été souligné que les tests de programme peuvent démontrer de manière convaincante la présence de bogues, mais ne peuvent jamais démontrer leur absence. Après avoir cité avec dévotion cette remarque très médiatisée, l'ingénieur logiciel revient à l'ordre du jour et continue d'affiner ses stratégies de test, tout comme l'alchimiste d'antan, qui a continué d'affiner ses purifications chrysocosmiques.
L'autre problème avec les tests unitaires est qu'ils créent un couplage étroit entre votre code et la suite de tests. Lorsque vous changez de code, vous vous attendez à ce que certains bogues apparaissent qui interrompent certains tests. Mais si vous modifiez le code parce que les exigences elles-mêmes ont changé, vous obtiendrez de nombreux tests qui échouent, et vous devrez parcourir manuellement chacun d'eux et décider si le test est toujours valide ou non. (Et il est également possible, bien que moins courant, qu'un test existant qui devrait invalide passe toujours parce que vous avez oublié de changer quelque chose qui devait être changé .)
Les tests unitaires ne sont que les derniers d'une longue lignée de modes de développement qui promettent de faciliter l'écriture de code de travail sans être un bon programmeur. Aucun d'entre eux n'a jamais réussi à tenir sa promesse, et celle-ci non plus. Il n'y a tout simplement pas de raccourci pour réellement savoir comment écrire du code de travail .
Certains rapports font état de tests automatisés réellement utiles dans les cas où la stabilité et la fiabilité sont d'une importance capitale. Par exemple, le projet de base de données SQLite. Mais ce qu'il faut pour atteindre leur niveau de fiabilité est très peu rentable pour la plupart des projets: un rapport test/code SQLite réel de près de 1200: 1. La plupart des projets ne peuvent pas se le permettre et n'en ont pas besoin de toute façon.
Si vous avez déjà vu l'avantage d'écrire une méthode principale pour tester un petit morceau de code pour l'école, le test unitaire est la version professionnelle/entreprise de cette même pratique.
Imaginez également les frais généraux liés à la création du code, au démarrage de votre serveur Web local, à la navigation vers la page en question, à la saisie des données ou à la définition de l'entrée dans la graine de test appropriée, à la soumission du formulaire et à l'analyse des résultats ... par rapport à la création et à la frappe le bouton d'exécution nUnit.
Voici aussi une image amusante ... 
J'ai trouvé cette image ici:
http://www.howtogeek.com/102420/geeks-versus-non-geeks-when-doing-repetitive-tasks-funny-chart/
Les tests unitaires ont quelque chose de mystique ces jours-ci. Les gens le traitent comme si une couverture de test à 100% était un Saint Graal, et comme si le test unitaire était la seule vraie façon de développer un logiciel.
Ils ratent le point.
Les tests unitaires ne sont pas la réponse. Test est.
Maintenant, à chaque fois que cette discussion apparaît, quelqu'un (souvent même moi) trottera la citation de Dijkstra: "Les tests de programme peuvent démontrer la présence de bogues, mais jamais démontrer leur absence." Dijkstra a raison: les tests ne sont pas suffisants pour prouver que le logiciel fonctionne comme prévu. Mais c'est nécessaire : à un certain niveau, il doit être possible de démontrer ce logiciel fait ce que vous voulez.
Beaucoup de gens testent à la main. Même les passionnés de TDD feront des tests manuels, bien qu'ils ne l'admettent parfois pas. Cela ne peut pas être aidé: juste avant d'entrer dans la salle de conférence pour faire la démonstration de votre logiciel à votre client/patron/investisseurs/etc., vous le parcourrez à la main pour vous assurer qu'il fonctionnera. Il n'y a rien de mal à cela, et en fait, il serait fou de s'attendre à ce que tout se passe bien sans le parcourir manuellement - c'est-à-dire le tester - même si vous avez une couverture de test unitaire à 100% et la plus grande confiance dans vos tests.
Mais les tests manuels, même s'ils sont nécessaires pour construire des logiciels, sont rarement suffisants . Pourquoi? Parce que les tests manuels sont fastidieux, prennent du temps et sont effectués par des humains. Et les humains sont notoirement mauvais pour effectuer des tâches fastidieuses et chronophages: ils évitent de les faire chaque fois que possible, et ils ne les font souvent pas bien quand ils sont obligés de le faire.
Les machines , d'autre part, sont excellentes pour effectuer des tâches fastidieuses et chronologiques -des tâches consommatrices. C'est pour cela que les ordinateurs ont été inventés, après tout.
Donc les tests sont cruciaux, et les tests automatisés sont le seul moyen sensé de assurez-vous que vos tests sont utilisés de manière cohérente. Et il est important de tester et de retester, au fur et à mesure du développement du logiciel. Une autre réponse ici note l'importance des tests de régression . En raison de la complexité des systèmes logiciels, des modifications fréquemment apparemment inoffensives d'une partie du système provoquent des modifications involontaires (c'est-à-dire des bogues) dans d'autres parties du système. Vous ne pouvez pas découvrir ces modifications involontaires sans une certaine forme de test. Et si vous souhaitez disposer de données fiables sur vos tests, vous devez effectuer vos tests de manière systématique, ce qui signifie que vous devez disposer d'une sorte de système de test automatisé.
Qu'est-ce que tout cela a à voir avec les tests unitaires? Eh bien, en raison de leur nature, les tests unitaires sont exécutés par la machine, pas par un humain. Par conséquent, de nombreuses personnes ont la fausse impression que les tests automatisés sont égaux les tests unitaires . Mais ce n'est pas vrai: les tests unitaires ne sont que de très petits tests automatisés .
Maintenant, quelle est la valeur dans les petits tests automatisés ? L'avantage est qu'ils testent les composants d'un système logiciel en isolation , ce qui permet plus précis ciblage des tests et aide au débogage . Mais les tests unitaires ne signifient pas intrinsèquement des tests de qualité supérieure . Cela conduit souvent à des tests de meilleure qualité, car il couvre les logiciels à un niveau de détail plus fin. Mais il est possible de tester complètement le comportement d'un système complet, et non ses pièces composites, et de le tester tout de même.
Mais même avec une couverture de test unitaire à 100%, un système peut ne pas encore être testé à fond. Parce que les composants individuels peuvent fonctionner parfaitement de manière isolée, mais échouent quand ils sont utilisés ensemble. Ainsi les tests unitaires, bien que très utiles, ne sont pas suffisants pour garantir que le logiciel fonctionne comme prévu. En effet, de nombreux développeurs complètent les tests unitaires par des tests d'intégration automatisés, des tests fonctionnels automatisés et des tests manuels.
Si vous ne voyez pas de valeur dans les tests unitaires, la meilleure façon de commencer est peut-être d'utiliser un autre type de test automatisé. Dans un environnement Web, l'utilisation d'un outil de test d'automatisation de navigateur comme Selenium fournira souvent une grande victoire pour un investissement relativement faible. Une fois que vous avez trempé vos orteils dans l'eau, vous pourrez plus facilement voir à quel point les tests automatisés sont utiles. Et une fois que vous avez des tests automatisés, les tests unitaires ont beaucoup plus de sens, car ils offrent un délai d'exécution plus rapide que les tests d'intégration ou de bout en bout, car vous pouvez cibler les tests uniquement sur le composant sur lequel vous travaillez actuellement.
TL; DR: ne vous inquiétez pas des tests unitaires pour l'instant. Il vous suffit de vous préoccuper de tester votre logiciel en premier.
Ça dépend
C'est une réponse que vous verrez beaucoup en matière de développement logiciel, mais l'utilité des tests unitaires dépend vraiment de la qualité de leur écriture. Un nombre nominal de tests unitaires qui vérifient la fonctionnalité de l'application pour les tests de régression peut être très utile; cependant, une pléthore de tests simples qui vérifient les retours de fonctions peuvent être tout à fait inutiles et fournir un faux sentiment de sécurité car l'application "a beaucoup de tests unitaires".
De plus, votre temps en tant que développeur est précieux et le temps passé à écrire des tests unitaires n'est pas du temps à écrire de nouvelles fonctionnalités. Encore une fois, cela ne veut pas dire que vous ne devriez pas écrire de tests unitaires, mais chaque fonction publique a-t-elle besoin d'un test unitaire? Je dirais que la réponse est non. Le code qui effectue la validation des entrées utilisateur nécessite-t-il des tests unitaires? Très probablement car il s'agit d'un point de défaillance commun dans les applications.
C'est l'un de ces domaines où l'expérience entre en jeu, au fil du temps, vous reconnaîtrez les parties de l'application qui pourraient bénéficier du test unitaire, mais il faudra un certain temps avant d'arriver à ce point.
Les projets réalisés pour les cours universitaires diffèrent considérablement des applications commerciales que vous rédigerez au travail. La différence est la durée de vie. Combien de temps dure un projet universitaire? Dans la plupart des cas, il commence lorsque vous écrivez la première ligne de code et se termine lorsque vous obtenez votre marque. On pourrait dire que, effectivement, il ne vit que le temps de la mise en œuvre. La "libération" est généralement égale à sa "mort".
Les logiciels conçus pour les entreprises dépassent ce point de sortie du projet universitaire et continuent de vivre aussi longtemps que les entreprises en ont besoin. Ce qui est très long . Quand on parle d'argent, personne ne dépensera un sou cassé pour avoir un "code plus frais et plus soigné". Si un logiciel écrit en C il y a 25 ans fonctionne toujours et est assez bon (tel que compris par les besoins de son propriétaire d'entreprise), attendez-vous à être invité à le maintenir (ajout de nouvelles fonctionnalités, amélioration des anciennes - modification du code source).
Nous arrivons à un point très important - régression . À l'endroit où je travaille, nous avons deux équipes qui gèrent deux applications; un, écrit il y a environ 5-6 ans avec très peu de couverture de tests de code *, et le second, une version plus récente de la première application avec à part entière suite de tests (unité, intégration et quoi d'autre) ). Les deux équipes ont des testeurs manuels (humains) dédiés. Vous voulez savoir combien de temps faut-il pour introduire une nouvelle fonctionnalité assez basique pour la première équipe? 3 à 4 semaines. La moitié de ce temps consiste à "vérifier si tout le reste fonctionne toujours". C'est une période chargée pour les testeurs manuels. Les téléphones sonnent, les gens se fâchent, quelque chose se casse à nouveau. La deuxième équipe traite généralement ces problèmes en moins de 3 jours.
Je ne dis en aucun cas que les tests unitaires rendent vos erreurs de code sujettes, correctes ou autres mots fantaisistes que vous pouvez trouver. Ils ne font pas non plus disparaître comme par magie les insectes. Mais lorsqu'ils sont combinés avec d'autres méthodes de test de logiciels automatisés, ils rendent vos applications beaucoup plus faciles à gérer qu'elles ne l'auraient été autrement. C'est une énorme victoire.
Et enfin et surtout, le commentaire de Brian qui, je pense, résout tout le problème:
(...) ils augmentent votre confiance (ou devraient ...) que le code fait ce que vous avez conçu pour faire, et continue de faire demain ce qu'il fait aujourd'hui.
Parce qu'entre aujourd'hui et demain, quelqu'un pourrait faire de minuscules modifications, ce qui entraînerait le crash du code du générateur de rapports oh-so-important. Tests Poussez les chances que vous le découvriez avant que votre client ne vous aide un peu.
* Ils introduisent lentement de plus en plus de tests dans leur base de code, mais nous savons tous à quoi cela ressemble habituellement.
est d'écrire des tests unitaires pour les formulaires Web ASP.NET quelque chose qui se fait souvent, et si c'est le cas: comment résoudre le problème de "l'environnement dynamique"?
Ce n'est pas souvent fait. Travailler avec des éléments d'interface utilisateur n'est pas un domaine dans lequel les tests unitaires sont bons, car il n'y a pas de moyen idéal pour vérifier par programme que les bonnes choses se retrouvent à l'écran aux bons endroits.
Me conseilleriez-vous de commencer à écrire des tests unitaires? Je pense que cela pourrait m'aider dans la mise en œuvre réelle, mais là encore, j'ai l'impression que cela pourrait me ralentir.
Le cas échéant, oui. Ils peuvent être très utiles pour vérifier des cas spécifiques de manière reproductible. Ils aident à agir comme une "friction" contre les changements gênants et comme une sécurité intégrée lorsque vous effectuez de meilleurs changements.
Une chose à noter est que ils vous ralentiront généralement.
Ça va.
Passer un peu de temps maintenant (s'il est bien fait) vous fera gagner du temps à l'avenir, car ils attrapent certains bogues, empêchent la récurrence de certains bogues et vous permettent d'être un peu plus à l'aise pour apporter d'autres améliorations au code pour l'empêcher de pourrir.
Je viens d'obtenir mon diplôme en CS et j'ai actuellement un emploi en tant que développeur junior .NET (en C # et généralement ASP.NET, formulaires Web - pas ASP.NET MVC). À l'époque où j'étais encore à l'université, le sujet des tests unitaires a été abordé, mais je n'en ai jamais vraiment vu les avantages.
C'est parce que vous n'avez jamais programmé grand.
Je comprends ce qu'il est censé faire - déterminer si un bloc de code est approprié ou non - mais je n'ai jamais eu à écrire de test unitaire auparavant. (ni> je n'ai jamais ressenti le besoin de ..)
L'écriture de tests unitaires oblige votre code à se conformer à une structure mentale donnée qui est testable, bien documentée et fiable. C'est bien plus que ce que vous prétendez.
-J'ai lu que les tests unitaires se produisent souvent en écrivant des "simulacres". Bien que je comprenne ce concept, je n'arrive pas à comprendre comment je suis censé écrire des simulations pour des sites Web qui sont complètement dynamiques, et où presque tout dépend des données provenant d'une base de données.
simulez l'accès à la base de données avec une classe simulée qui renvoie des classes de modèle remplies de données bien définies et codées en dur. ou , remplissez une base de données de test avec des données de luminaire et travaillez à partir de là.
-Avez-vous les gars me conseiller de commencer à écrire des tests unitaires?
putain, oui. Lisez d'abord Beck's "Test Driven Development" .
Je pense que cela pourrait m'aider dans la mise en œuvre réelle, mais là encore, j'ai l'impression que cela pourrait me ralentir.
Cela vous ralentit maintenant. Mais lorsque vous devez déboguer pendant des heures au lieu de jours, vous changez d'avis.
n'importe quel conseil sera apprécié :)
Tester. Croyez-moi. Malheureusement, cela doit aussi être une politique de gestion, mais c'est quelque chose qui fait gagner du temps. Les tests restent, ils sont là, maintenant et dans le futur. Lorsque vous changez de plate-forme et exécutez les tests, et qu'ils fonctionnent toujours, vous savez que votre travail fonctionne comme prévu.
Edit: J'ai bien sûr rejoint le dogpile TDD pro/con et sauté la question # 1:
1 - Implémentation de tests unitaires dans les formulaires Web ASP.net:
Tout d'abord, si vous pensez que vous pouvez les faire partir avec MVC, combattez-le comme un ours des cavernes enragé. En tant que développeur front-end/UI, .net MVC m'a aidé à arrêter de détester .net afin que je puisse mieux me concentrer sur la haine de chaque Java solution web que j'ai jamais rencontrée. Les tests unitaires sont problématiques parce que les formulaires Web brouillent vraiment les lignes entre le serveur et le côté client. Dans toute tentative de faire des tests unitaires, je mettrais l'accent sur la manipulation des données et (espérons-le) je suppose que les formulaires Web gèrent la normalisation des entrées utilisateur pour vous sous le capot.
2 - Sur la pertinence des tests unitaires:
Très bien, divulgation complète:
- Je suis principalement autodidacte. Ma formation formelle se résume à aimer un JavaScript, un PHP et une classe C # et ma propre étude personnelle des principes OOP et lecture de choses comme Design Patterns).
Cependant,
- J'écris principalement pour le Web côté client et la partie de programmation réelle est dans l'un des langages les plus rapides et les plus lâches en ce qui concerne le typage dynamique, les fonctions de première classe et la mutabilité des objets.
Cela signifie que je n'écris pas pour le même compilateur ou la même machine virtuelle. J'écris pour 4 à 20 interprétations différentes de trois langues (oui, deux d'entre elles sont simplement déclaratives mais déterminent également l'espace physique fondamental de l'interface utilisateur avec laquelle je travaille parfois de différentes manières) et je le fais depuis que les interprétations étaient un beaucoup plus varié qu'aujourd'hui. Et non, je ne suis pas seulement un gamin qui branche des trucs JQuery pour des applications jetables. J'aide à construire et à maintenir des choses assez sophistiquées avec beaucoup de complexité d'élément d'interface utilisateur.
Alors oui, il y a beaucoup d'opportunités pour quelques ajustements ici et là pour créer une cascade massive d'échecs si vos compétences en conception sont complètement nulles ou si vous lancez des développeurs médiocres en grande quantité à 1-2 problèmes de développement de qualité.
Ma compréhension de ce que TDD est censé faire pour vous, c'est que les tests visent vraiment à vous forcer à considérer la conception plus attentivement et à vous concentrer sur les exigences. C'est juste, mais le problème ici est qu'il subvertit ce que vous devriez faire, qui est de concevoir une interface, en quelque chose de subtilement mais fondamentalement différent, qui est de concevoir pour les tests d'une interface. La différence pour moi est entre dessiner une image claire dont maman n'aura pas à deviner le sens et remplir toute la page de vert très rapidement afin que vous puissiez être le premier enfant à gifler ses crayons sur la table et crier "c'est fait!" " En déplaçant la priorité sur les résultats plutôt que sur le processus et la conception, vous encouragez fondamentalement la mise en œuvre continue du code poubelle, qui est généralement ce qui était à l'origine de vos problèmes en premier lieu.
Et puis, bien sûr, il y a le "côté non réel", mais l'avantage souvent apprécié des tests unitaires eux-mêmes, vous aidant à détecter les erreurs de régression. Les partisans du TDD ont tendance à être un peu insipides quant à savoir si c'est réellement l'objectif ou juste un effet secondaire astucieux, OMI, car ils savent très bien ou soupçonnent au moins que cela n'est tout simplement pas suffisant pour établir l'absence de bogues dans votre du code, en particulier dans un langage plus dynamique comme JavaScript où supposer que vous pouvez même prédire tous les scénarios possibles dans une longue chaîne de dépendances est imprudent.
Il y a une place pour les tests automatisés dans JS, mais une meilleure utilisation de votre temps que d'attacher un test unitaire à chaque `` unité '' de votre code qui entre en contact avec un autre est de vous assurer que vous n'avez pas un tas de les ordures qui dupliquent le travail ou dont l'usage prévu est sémantiquement ambigu là-dedans en premier lieu. Vous suivez le principe DRY. Vous extrayez les choses à des fins de réutilisation/portabilité lorsque la valeur de le faire devient apparente (et pas une minute avant). Vous établissez des processus et des façons cohérents de faire les choses suivre plus le principe de la carotte que du bâton (c'est-à-dire qu'il est trop facile d'utiliser vos trucs de la bonne façon pour ne pas vouloir le faire de la mauvaise façon). anti-patterns comme moyen de réutilisation du code.
Tout ce qui précède m'a aidé à réduire sérieusement les bogues difficiles à diagnostiquer dans mon code et vous pouvez avoir confiance que c'est une grande priorité pour quelqu'un qui est venu en tant que développeur avec un ensemble de navigateurs qui n'avait rien de mieux à vous dire que " euh il y a eu un problème avec un objet de type "Object" à ce numéro de ligne imaginaire dans un fichier non spécifié. " (gee, merci IE6) TDD, dans ma ligne de travail, n'encouragerait pas ces choses. Cela déplacerait le focus vers des résultats à 100% par rapport au processus où ce qui est entre le point A et B n'a pas vraiment d'importance tant qu'il fonctionne. C'est une perte de temps qui serait mieux appliquée pour s'assurer que vos trucs sont lisibles, portables et faciles à modifier sans beaucoup de brouillage déroutant en premier lieu.
Ou peut-être que je suis trop en train de tourner en rond le paradigme dans lequel je suis enraciné, mais à mon avis, le faire correctement en premier lieu est une utilisation beaucoup plus efficace du temps que de couvrir vos fesses lorsque vous ou tout le monde sur votre l'équipe le fait mal. Et rien ne devrait vous obliger à considérer la conception plutôt que de simplement mettre les choses en œuvre. Le design devrait être l'autel effrayant de chaque programmeur. Et tout ce qui "vous oblige" à faire la bonne chose ou vous protège de vous-même doit être considéré avec le même soupçon réservé aux bouteilles d'huile de serpent, l'OMI. L'huile de serpent dans l'informatique moderne et le développement général, si vous ne le savez pas encore, est vendue à la tonne liquide.
D'après mon expérience, les tests unitaires sont en effet très utiles, lorsque vous commencez avec eux et restez avec eux c'est-à-dire le développement piloté par les tests. Voici pourquoi:
Les tests unitaires vous obligent à réfléchir à ce que vous voulez, et comment vérifier que vous l'avez obtenu, avant d'écrire le code qui le fait. Dans un scénario TDD, vous écrivez d'abord le test. Vous devez donc savoir ce que le code que vous vous apprêtez à écrire doit faire et comment vous pouvez vérifier qu'il l'a fait avec succès, afin d'écrire un test "rouge" que vous rendrez ensuite "vert" en écrivant le code dans passe-le. Dans de nombreux cas, cela vous oblige à réfléchir un peu plus à l'algorithme que vous êtes sur le point d'écrire pour réussir ce test, ce qui est toujours une bonne chose car il réduit les erreurs logiques et les "cas d'angle". Pendant que vous écrivez le test, vous vous demandez "comment cela pourrait échouer" et "que suis-je pas tester ici ", ce qui conduit à un algorithme plus robuste.
Les tests unitaires vous obligent à réfléchir à la façon dont le code que vous vous apprêtez à écrire sera consommé. Avant d'apprendre TDD, il y avait BEAUCOUP de fois où j'écrivais du code s'attendant à ce qu'une dépendance fonctionne dans un sens, puis une dépendance écrite par un collègue fonctionnait d'une manière complètement différente. Bien que cela soit toujours possible avec TDD, le test unitaire que vous écrivez vous oblige à réfléchir à la façon dont vous souhaitez utiliser l'objet que vous écrivez, car il s'agit d'un exemple d'utilisation dudit objet. J'espère que vous écrirez alors l'objet de manière à ce qu'il soit facile à consommer, et donc à l'adapter si nécessaire (bien que la programmation sur des interfaces prédéfinies soit une meilleure solution globale à ce problème qui ne nécessite pas TDD).
Les tests unitaires vous permettent de "coder en testant". Un outil de refactorisation comme ReSharper peut être votre meilleur ami si vous le permettez. Vous pouvez l'utiliser pour définir le squelette de nouvelles fonctionnalités lorsque vous définissez l'utilisation dans un test.
Par exemple, disons que vous devez créer un nouvel objet MyClass. Vous commencez par créer une instance de MyClass. "Mais MyClass n'existe pas!", Se plaint ReSharper. "Ensuite, créez-le", dites-vous en appuyant sur Alt + Entrée. Et hop, vous avez votre définition de classe. Dans la ligne suivante de code de test, vous appelez une méthode MyMethod. "Mais cela n'existe pas!", Explique ReSharper. "Ensuite, créez-le", répétez-vous, avec un autre Alt + Entrée. Vous avez, en quelques touches, défini le "squelette" de votre nouveau code. Alors que vous continuez à étoffer l'utilisation, le IDE vous dira quand quelque chose ne va pas, et généralement la solution est assez simple pour que le IDE ou un outil qui s'y branche sait comment y remédier.
Des exemples plus extrêmes sont conformes au modèle "Triple-A"; "Arrangez, Agissez, Affirmez". Configurez tout, effectuez la logique réelle que vous testez, puis assurez-vous que la logique est correcte. En codant de cette manière, il est très naturel de coder la solution dans le test; puis, avec quelques touches, vous pouvez extraire cette logique et la placer quelque part où elle peut être utilisée dans le code de production, puis apporter de petites modifications au test qui la dirigent vers le nouvel emplacement de la logique. Le faire de cette façon vous oblige à concevoir le code de manière modulaire et facile à réutiliser car les unités que vous testez doivent toujours être accessibles.
Les tests unitaires exécutent de nombreux ordres de grandeur plus rapidement que tout test manuel auquel vous pourriez penser. Il y a un point, très rapidement rencontré dans le cas de projets plus importants, où le temps supplémentaire des tests unitaires commence à payer lui-même en réduisant le temps passé à tester manuellement. Vous devez TOUJOURS exécuter le code que vous venez d'écrire. Traditionnellement, vous le faisiez manuellement, en démarrant un grand programme, en naviguant dans l'interface utilisateur pour configurer la situation pour laquelle vous avez modifié le comportement, puis en vérifiant à nouveau les résultats via l'interface utilisateur ou sous la forme de données produites. Si le code a été TDDed, vous exécutez simplement les tests unitaires. Je vous garantis que si vous écrivez de bons tests unitaires, cette dernière option sera beaucoup plus rapide que la première.
Les tests unitaires capturent la régression. Encore une fois, il y a eu plusieurs fois avant d'apprendre TDD où je suis entré, d'apporter ce que je pensais être un changement chirurgical à un morceau de code, de vérifier que le changement corrigeait un comportement errant (ou produisait un nouveau comportement souhaité) dans la situation signalée , et l'a archivée pour publication, seulement pour constater que le changement a cassé un autre cas de coin dans un module complètement différent qui est arrivé à réutiliser ce même bloc de code. Dans un projet TDDed, je peux écrire un test vérifiant une modification que je suis sur le point de faire, apporter la modification, puis exécuter la suite complète, et si toutes les autres utilisations du code ont été TDDed et que ma modification a cassé quelque chose, les tests pour ceux d'autres choses échoueront et je pourrai enquêter.
Si les développeurs devaient trouver et tester manuellement toutes les lignes de code qui pourraient être affectées par un changement potentiel, rien ne serait jamais fait car le coût de la détermination de l'impact d'un changement rendrait le changement impossible. À tout le moins, rien ne serait SOLID et donc facilement entretenu, car vous n'oseriez jamais toucher à quelque chose qui peut être utilisé à plusieurs endroits; vous devriez plutôt lancer votre propre très similaire, mais- incorporant votre solution de changement mineur pour ce cas, violant SRP et probablement OCP, et transformant lentement votre base de code en une courtepointe patchwork.
Les tests unitaires façonnent l'architecture d'une manière généralement avantageuse. Les tests unitaires sont des tests effectués indépendamment de toute autre logique. Pour pouvoir tester votre code à l'unité, vous devez alors écrire le code de telle sorte que vous puissiez l'isoler. Les bonnes décisions de conception telles que le couplage lâche et l'injection de dépendance se détachent donc naturellement du processus TDD; les dépendances doivent être injectées de sorte que dans un test, vous puissiez injecter un "faux" ou "stub" qui produit l'entrée ou gère la sortie pour la situation testée sans créer "d'effets secondaires". La mentalité de "l'utilisation d'abord" de TDD mène généralement au "codage vers les interfaces", l'essence du couplage lâche. Ces bons principes de conception vous permettent ensuite d'apporter des modifications à la production, comme le remplacement d'une classe entière, sans nécessiter de modification de grandes masses de la base de code pour s'adapter.
Les tests unitaires montrent que le code fonctionne, au lieu de prouver le code fonctionne. À première vue, vous pourriez penser que c'est un inconvénient; la preuve vaut-elle mieux que la démonstration? La théorie est géniale; la théorie computationnelle et algorithmique est le fondement de notre travail. Mais, une preuve mathématique d'exactitude d'un algorithme n'est pas une preuve de exactitude de l'implémentation . Une preuve mathématique montre seulement que le code adhérant à l'algorithme doit être correct. Un test unitaire montre que le code réellement écrit fait ce que vous pensiez qu'il ferait, et est donc la preuve qu'il est correct. Ceci est généralement beaucoup plus valable tout autour qu'une preuve théorique.
Maintenant, tout cela dit, les tests unitaires présentent des inconvénients:
Vous ne pouvez pas tout tester à l'unité. Vous pouvez concevoir votre système pour minimiser le nombre de LOC non couverts par un test unitaire, mais il y aura tout simplement certaines zones du système qui ne pourront pas être testées unitaire. Votre couche d'accès aux données peut être ridiculisée lorsqu'elle est utilisée par un autre code, mais la couche d'accès aux données elle-même contient beaucoup d'effets secondaires et il n'est généralement pas possible de tester un peu (la plupart?) D'un référentiel ou d'un DAO. De même, le code qui utilise des fichiers, établit des connexions réseau, etc. a des effets secondaires intégrés et vous ne pouvez tout simplement pas tester à l'unité la ligne de code qui fait cela. Les éléments d'interface utilisateur ne peuvent souvent pas être testés à l'unité; vous pouvez tester le code derrière des méthodes telles que les gestionnaires d'événements, vous pouvez tester les constructeurs unitaires et vérifier que les gestionnaires sont connectés, mais il n'y a tout simplement pas de substitut dans le code pour qu'un utilisateur clique avec la souris sur un élément graphique particulier et regarde le gestionnaire être appelé. Atteindre ces limites entre ce qui peut et ne peut pas être testé de manière adéquate est appelé "gratter le bord du bac à sable"; au-delà de ce point, vous êtes limité à utiliser des tests d'intégration, des tests d'acceptation automatisés et des tests manuels pour vérifier le comportement.
De nombreux avantages des tests unitaires ne s'appliquent pas sans TDD. Il est parfaitement possible d'écrire du code, puis d'écrire des tests qui exercent le code. Ce sont toujours des "tests unitaires", mais en écrivant d'abord du code, vous perdez de nombreux avantages inhérents au développement "test en premier": le code n'est pas nécessairement architecturé d'une manière qui peut être facilement testée, ou même utilisée en production. ; vous n'obtenez pas le processus de réflexion "à double vérification" inhérent à la rédaction du test et à la réflexion sur ce à quoi vous n'aviez pas pensé; vous ne codez pas en testant; et si vous écrivez du code, testez-le manuellement et voyez-le fonctionner, puis codez un test unitaire qui échoue, ce qui est faux, le code ou le test? Vos principaux avantages sont la prévention de la régression (vous serez averti lorsque le code qui a déjà réussi ses tests échoue maintenant) et la vérification à grande vitesse par rapport aux tests manuels. La perte des autres avantages de TDD peut faire pencher la balance loin de l'utilisation de tests unitaires.
Les tests unitaires introduisent une surcharge. Tout simplement, vous écrivez du code pour tester le code que vous écrivez. Cela augmentera nécessairement le LOC total d'un projet de développement, et oui, le LOC pour les tests peut dépasser le LOC pour le projet réel. Les développeurs et les non-développeurs naïfs examineront cet état de fait et diront que les tests sont une perte de temps.
Les tests unitaires nécessitent de la discipline. Vous devez écrire des tests qui exerceront correctement la base de code (bonne couverture de code), vous devez les exécuter régulièrement (comme à chaque fois que vous effectuez un changement, la suite complète doit être exécutée), et vous devez tout garder "vert" ( tous les tests réussissent). Lorsque les choses se cassent, vous devez les corriger soit en corrigeant du code qui ne répond pas aux attentes, soit en mettant à jour les attentes des tests. Si vous changez les tests, vous devriez demander "pourquoi" et surveiller de très près vous-même; il est incroyablement tentant de simplement changer les assertions qui échouent pour correspondre au comportement actuel, ou simplement de supprimer les tests qui échouent; mais, ces tests doivent être basés sur les exigences, et lorsque les deux ne correspondent pas, vous avez un problème. Si ces choses ne sont pas faites, les tests n'ont aucune valeur une fois que vous les utilisez pour montrer le code que vous écrivez réellement lorsque vous avez touché le test pour la dernière fois (ce qui était de prouver que votre développement initial ou votre changement chirurgical a fait ce que vous pensiez). quand vous l'avez écrit).
Les tests unitaires nécessitent plus d'équipement. La solution habituelle au besoin de discipline ci-dessus, et à une tendance naturelle des humains à devenir paresseux et complaisants, est un "build-bot" exécutant un progiciel "d'intégration continue" comme TeamCity, CruiseControl, etc., qui effectue des tests unitaires, calcule des mesures de couverture de code, et dispose d'autres contrôles tels que "triple-C" (conformité à la convention de codage, à la FxCop). Le matériel du build-bot doit être raisonnablement performant (sinon il ne suivra pas le taux d'enregistrement de code que l'équipe moyenne fera), et les procédures d'enregistrement sur le bot doivent être tenues à jour (si une nouvelle bibliothèque de tests unitaires est créée, les scripts de construction qui exécutent les tests unitaires doivent être modifiés pour apparaître dans cette bibliothèque). C'est moins de travail qu'il n'y paraît, mais cela nécessite généralement une certaine expertise technique de la part d'au moins quelques personnes de l'équipe qui savent comment fonctionnent les différents processus de construction (et peuvent donc les automatiser dans des scripts et maintenir lesdits scripts) . Cela nécessite également de la discipline sous la forme d'une attention lorsque la construction "se casse", et de réparer tout ce qui a causé la rupture (correcte) avant de vérifier quelque chose de nouveau.
Les tests unitaires peuvent forcer l'architecture du code d'une manière non idéale. Bien que TDD soit généralement bon pour la modularité et la réutilisabilité du code, il peut nuire à l'accessibilité appropriée du code. Les objets et les membres, placés dans des bibliothèques de production, ne peuvent pas être privés ou internes s'ils sont directement utilisés par des tests unitaires. Cela peut causer des problèmes lorsque d'autres codeurs, voyant maintenant un objet, essaient de l'utiliser alors qu'ils devraient plutôt utiliser quelque chose d'autre présent dans la bibliothèque. Les révisions de code peuvent aider à cela, mais cela peut être une préoccupation.
Les tests unitaires interdisent généralement les styles de codage "développement rapide d'applications". Si vous écrivez des tests unitaires, vous ne codez pas "rapidement et librement". C'est généralement une bonne chose, mais lorsque vous êtes dans un délai imposé de l'extérieur de votre contrôle, ou que vous mettez en œuvre un changement de très petite envergure et que la partie prenante (ou votre patron) se demande pourquoi toute cette cruauté doit arriver juste pour changer une ligne de code, il peut tout simplement être impossible d'écrire et de maintenir la suite de tests unitaires appropriée. Les processus agiles aident généralement à cela en permettant aux développeurs d'avoir leur mot à dire sur les exigences de temps; rappelez-vous, tout ce que le vendeur a à faire est de dire "oui, nous pouvons" et il obtient le chèque de commission, à moins que le processus n'implique que les personnes qui doivent réellement faire le travail disent "non, nous ne pouvons pas" et que l'on y prête attention. Mais, tout le monde n'est pas agile, et Agile a ses propres limites.
Une chose qui ne semble pas être abordée est la complexité de tester différents types de code.
Lorsque vous traitez des choses avec des entrées et des sorties simples, il est généralement facile de tester les unités et si les tests sont choisis en tenant compte des cas Edge du code testé, ils vous donneront beaucoup de confiance qu'ils ont raison. Ne pas écrire de tests pour un tel code serait fou. (Notez que la plupart du code qui va dans les bibliothèques répond à ces critères.)
Cependant, dans d'autres cas, vous finissez par devoir construire d'énormes simulations à tester parce que le code joue avec des données sous-jacentes complexes (généralement une base de données mais ce n'est pas obligatoire) ou produit des données de sortie très complexes (pensez à une routine qui tourne une valeur de départ dans un niveau de jeu pour un exemple assez extrême) et les tests unitaires ne sont pas aussi utiles. Couvrir tout dans vos cas de test est généralement un rêve de pipe et quand vous trouvez un bogue, c'est presque toujours un cas auquel vous n'avez jamais pensé et ne pourrait donc pas avoir construit un test de toute façon.
Il n'y a pas de balles d'argent, tout ce qui est décrit comme une balle d'argent n'est pas aussi bon que ses partisans le prétendent, mais cela ne signifie pas qu'il est inutile.
Les tests unitaires sont utiles lorsqu'ils sont utilisés correctement; il y a divers problèmes avec votre logique.
"Quand je me développe, je passe par beaucoup d'essais et d'erreurs", a déclaré Kevin.
Regardez la programmation par coïncidence. Il vaut mieux comprendre ce qu'un code doit faire et prouver ensuite qu'il le fait via un test unitaire. Ne supposez pas qu'un code fonctionne simplement parce que l'interface utilisateur ne s'est pas cassée lorsque vous avez exécuté le programme!
s writing unit tests for ASP.NET web forms something that is done often
Je n'ai aucune connaissance des données statistiques pour dire à quelle fréquence les gens testent les formulaires Web. Ce n'est pas important. L'interface utilisateur est difficile à tester et les tests unitaires ne doivent pas non plus être couplés à une interface utilisateur. Séparez votre logique en couches, bibliothèques de classes qui peuvent être testées. Testez l'interface utilisateur séparément de la logique principale.
So, question number 2: Would you guys advise me to start writing unit tests?
Oui. Une fois que vous vous y êtes habitué, ils vous accélèrent. La maintenance est beaucoup plus longue et coûteuse que la phase de développement initiale. La maintenance est grandement facilitée par les tests unitaires, même avec les tests initiaux et la réparation des bogues.
L'écriture de tests unitaires pour l'application de formulaires Web ASP.NET n'est PAS courante et très difficile à accomplir. Cependant, cela ne signifie pas que le projet doit l'ignorer.
Les tests unitaires sont corner stones des applications critiques et offrent une fiabilité et une tranquillité d'esprit que les fonctionnalités de base fonctionnent comme prévu.
En fait, vous pouvez introduire les tests unitaires beaucoup plus facilement avec un modèle ASP.NET MVP qui pourrait être utilisé dans le développement de vos formulaires Web. Il introduira une séparation des préoccupations et ability to write essential unit tests.
Voici quelques références qui pourraient être utiles à rechercher:
Sur le plan pratique, les tests unitaires peuvent être extrêmement utiles pour une raison très importante: Vous pouvez tester un bit de code à la fois.
Lorsque vous écrivez toute une séquence d'étapes complexes et que vous les déboguez à la fin, vous avez tendance à trouver de nombreux bogues, et le processus est généralement plus difficile car vous êtes plus avancé dans le processus. Dans Visual Studio, vous pouvez générer un test rapide, le modifier un peu et exécuter UNIQUEMENT ce test .. Vous savez alors que, par exemple, une méthode appelant cette méthode peut s'appuyer sur elle. Cela augmente donc la confiance.
Les tests unitaires ne prouvent pas que votre programme est correct!: Les tests unitaires vérifient les régressions dans le code sensible et vous permettent de tester les nouvelles méthodes que vous écrivez.
Les tests unitaires ne sont pas destinés à tester les frontaux: Considérez un test unitaire comme ce petit projet que vous créez pour tester une nouvelle méthode que vous écrivez ou quelque chose, pas comme une sorte de condition dont votre code a besoin rencontrer.
Les tests unitaires fonctionnent très bien pour les environnements collaboratifs: Si je dois fournir une méthode à un collègue qui utilise une technologie complètement différente de la mienne, comme par exemple, il l'appelle depuis iOS, alors je peux rapidement écrire un test unitaire pour voir si la méthode qu'il veut a) Retruns les bonnes données b) Effectue selon ses spécifications c) N'a pas de goulots d'étranglement désagréables.
Le but des tests unitaires est de vous permettre de changer votre code en toute sécurité (refactoring, amélioration etc.) sans craindre de casser quelque chose à l'intérieur du système. Cela s'avère très utile pour les grandes applications, lorsque vous ne connaissez pas vraiment tous les effets de votre changement de code (malgré un couplage lâche).
D'après mon expérience, oui, les tests unitaires sont utiles.
Le test unitaire consiste à séparer les parties du code que vous écrivez et à vous assurer qu'elles fonctionnent isolément. Cet isolement peut en effet impliquer la création de faux ou de faux objets pour parler à l'objet que vous testez, ou il peut ne pas l'être. Cela dépend beaucoup de l'architecture de votre objet.
Les tests unitaires accordent divers avantages:
Principalement, cela garantit que les unités que vous testez fonctionnent comme vous, le développeur, pensez qu'elles devraient fonctionner. Bien que cela soit inférieur à ce qu'il semble: cela ne signifie pas nécessairement que l'objet fonctionne correctement; seulement que cela fonctionne comme vous pensez que cela devrait fonctionner, c'est une déclaration beaucoup plus forte que la méthode d'essai et d'erreur qui est nécessaire sans test unitaire.
De plus, il garantit que les unités continuent de fonctionner comme vous, le développeur, pensiez qu'elles devraient fonctionner. Modifications du logiciel, ce qui peut affecter les unités de manière inattendue.
Un autre effet secondaire est que cela signifie que les unités que vous testez fonctionnent isolément. Cela signifie généralement que vous commencez à programmer sur des interfaces plutôt que sur des classes concrètes, réduisant le couplage et augmentant la cohésion: toutes les caractéristiques communes d'une bonne conception. Oui: simplement permettre à vos unités de code d'avoir des tests unitaires améliorera naturellement la conception de votre code.
Cependant ...
Les tests unitaires ne sont pas la fin des tests. D'autres types de tests sont encore nécessaires. Par exemple, même lorsque vous avez montré que les unités fonctionnent comme vous vous attendez à ce qu'elles fonctionnent, vous devez toujours montrer que chaque unité fonctionne comme les unités qui lui parlent s'attendent à ce qu'elle fonctionne. Autrement dit, vos composants s'intègrent-ils correctement entre eux?
Je veux ajouter un nouveau côté (en fait, un assez ancien) à ceci: les tests unitaires ne sont pas très utiles si votre code est bien conç.
Je sais que la plupart des programmeurs ne font plus de conception de programme, je le fais toujours, et j'ai trouvé que les tests unitaires étaient une nécessité assez longue pour s'intégrer dans une culture TDD, mais jusqu'à présent, je n'ai rencontré que 1-2 mineurs bogues pour des milliers de lignes de tests de mon code - pas seulement ce que j'ai écrit, mais aussi ce que les testeurs officiels ont écrit.
Je suppose que vous ne ferez plus de conception de programme non plus - les gens actuels vous forceront à ne pas le faire - mais il vaut peut-être la peine de se rappeler que le test unitaire est une méthode d'efficacité très-très faible par rapport à la conception.
C'est un argument dijsktraian: le test unitaire ne peut être exécuté que sur un programme suffisamment détaillé pour être exécuté.
Si vous dessinez des organigrammes/diagrammes d'état/d'action, des diagrammes de séquence, des inventaires d'objets (et enfin des diagrammes de classe ET) pour votre code avant de l'écrire, vous pourrez éliminer la plupart des bogues potentiellement menaçants simplement en traçant vos lignes et vérifier vos noms.
De nos jours, les diagrammes de classes sont générés à partir de code, contenant des centaines, parfois des milliers de classes et sont complètement inutilisables - tout ce qui contient plus de 15 éléments est au-delà de la reconnaissance humaine.
Vous devez savoir ce qui compte pour 10 + -5 classes ou ce que vous faites en ce moment, et être en mesure de vérifier votre code à partir de plusieurs points de vue, chaque diagramme représentant EXACTEMENT les points de vue que vous regardez, et vous éliminerez des milliers de bogues sur papier.
- Vérifier dans un code dynamique si les types sont respectés (en affichant simplement les types d'entrée/sortie sur un organigramme et en les connectant avec un crayon ou une couleur différente),
- vérifier si tous les états sont traités (en vérifiant l'intégralité de vos conditions),
- tracer les lignes pour s'assurer que tout se termine (chaque organigramme doit être un automate à états finis déterministe entièrement défini, pour les mathématiciens
- s'assurer que certains composants n'ont rien à voir les uns avec les autres (en extrayant toutes leurs dépendances) (bon pour la sécurité)
- simplifier le code en convertissant les dépendances en associations (les dépendances proviennent des classes que les méthodes membres utilisent)
- vérification des noms, recherche de préfixes communs, effacement de synonymes etc ...
il y a tellement plus facile ...
De plus, j'ai découvert que mes applications sont plus utilisables, si elles proviennent directement de cas d'utilisation ... si les cas d'utilisation sont bien écrits (sujet verbe ACTOR, demande du mainteneur d'ouvrir un distributeur automatique de billets) ...
J'ai fait du code avec 95 +% des couvertures de code. Bien sûr, je fais parfois des tests unitaires, en particulier. pour les vérifications des limites dans les calculs, mais je n'ai pas encore rencontré de régressions graves (grave: ne disparaît pas dans les 24 heures) pour ne pas utiliser les tests unitaires même pour les refactorisations.
Parfois, je ne fais pas une seule ligne de code pendant 3-4 jours d'affilée, je dessine juste. Puis, en une journée, je tape 1500-2000 lignes. Le lendemain, ils sont pour la plupart prêts pour la production. Parfois des tests unitaires sont écrits (avec 80 +% de couverture), parfois (en plus) les testeurs sont invités à essayer de le casser, à chaque fois, certaines personnes sont invitées à le réviser en le regardant.
Je n'ai pas encore vu ces tests unitaires trouver quoi que ce soit.
Je souhaite que le design-thinking remplace le TDD ... mais TDD est tellement plus facile, c'est comme aller avec un marteau ... la conception a besoin de réflexion, et vous êtes absent pour le clavier la plupart du temps.
Pour les applications simples avec un petit nombre de couches à tester (fenêtre principale -> sous-menu), peut-être que la compilation à exécuter pour vérifier les modifications est correcte.
Pour les applications plus grandes où il faut 30 secondes de navigation pour obtenir la page que vous testez, cela finit par être très cher.