Comment testez-vous un test unitaire?

Je regardais les webcasts de Rob Connerys sur l’application MVCStoreFront, et j’ai remarqué qu’il était en train de tester les choses les plus banales, par exemple:

public Decimal DiscountPrice { get { return this.Price - this.Discount; } } 

Aurait un test comme:

 [TestMethod] public void Test_DiscountPrice { Product p = new Product(); p.Price = 100; p.Discount = 20; Assert.IsEqual(p.DiscountPrice,80); } 

Alors que je suis tout pour les tests unitaires, je me demande parfois si cette forme de premier développement de test est vraiment bénéfique, par exemple, dans un processus réel, vous avez 3-4 couches au-dessus de votre code (Business Request, Requirements Document, Architecture Document) , où la règle métier définie (prix d’escompte est le prix – remise) peut être mal définie.

Si c’est le cas, votre test unitaire ne vous dit rien.

De plus, votre test unitaire est un autre point d’échec:

 [TestMethod] public void Test_DiscountPrice { Product p = new Product(); p.Price = 100; p.Discount = 20; Assert.IsEqual(p.DiscountPrice,90); } 

Maintenant, le test est défectueux. Evidemment, dans un test simple, ce n’est pas grave, mais disons que nous testons une règle métier compliquée. Que gagnons-nous ici?

Deux ans plus tard, les développeurs de maintenance le conservent. Maintenant que l’entreprise change de règle et que le test recommence, certains développeurs novices corrigent le test de manière incorrecte … nous avons maintenant un autre sharepoint défaillance.

Tout ce que je vois est des points de défaillance plus possibles, sans retour bénéfique réel, si le prix de la remise est erroné, l’équipe de test trouvera toujours le problème, comment les tests unitaires ont-ils sauvé du travail?

Qu’est-ce que j’oublie ici? S’il vous plaît apprenez-moi à aimer TDD, car j’ai du mal à l’accepter comme utile jusqu’à présent. Je veux aussi, parce que je veux restr progressiste, mais cela n’a tout simplement aucun sens pour moi.

EDIT: Quelques personnes ont mentionné que les tests aident à appliquer les spécifications. D’après mon expérience, la spécification était également erronée, mais je suis peut-être condamné à travailler dans une organisation où les spécifications sont écrites par des personnes qui ne devraient pas écrire de spécifications.

Premièrement, les tests sont comme la sécurité – vous ne pouvez jamais être sûr à 100% que vous les avez, mais chaque couche ajoute plus de confiance et un cadre pour résoudre plus facilement les problèmes qui restnt.

Deuxièmement, vous pouvez diviser les tests en sous-routines qui peuvent ensuite être testées. Lorsque vous avez 20 tests similaires, faire un sous-programme (testé) signifie que votre test principal consiste en 20 invocations simples du sous-programme, ce qui est beaucoup plus probable.

Troisièmement, certains diraient que TDD répond à cette préoccupation. Autrement dit, si vous écrivez simplement 20 tests et qu’ils réussissent, vous n’êtes pas complètement sûr qu’ils testent réellement quelque chose. Mais si chaque test que vous avez écrit initialement a échoué , et puis vous l’avez corrigé, alors vous êtes beaucoup plus sûr que cela teste vraiment votre code. IMHO ce va-et-vient prend plus de temps que cela en vaut la peine, mais c’est un processus qui tente de répondre à vos préoccupations.

Un test erroné est peu susceptible de casser votre code de production. Au moins, pas pire que de ne pas avoir de test du tout. Ce n’est donc pas un “sharepoint défaillance”: les tests ne doivent pas nécessairement être corrects pour que le produit fonctionne réellement. Ils devront peut-être être corrects avant d’être validés, mais le processus de correction des tests cassés ne met pas en danger votre code d’implémentation.

Vous pouvez penser à des tests, même sortingviaux, comme ceux-ci, comme étant un deuxième avis sur ce que le code est censé faire. Une opinion est le test, l’autre est la mise en œuvre. S’ils ne sont pas d’accord, alors vous savez que vous avez un problème et que vous regardez de plus près.

Il est également utile que quelqu’un, à l’avenir, souhaite implémenter la même interface à partir de rien. Ils ne devraient pas avoir à lire la première implémentation pour savoir ce qu’est la remise, et les tests agissent comme une sauvegarde sans ambiguïté de toute description écrite de l’interface.

Cela dit, vous échangez du temps. S’il y a d’autres tests que vous pourriez écrire en utilisant le temps que vous économisez en évitant ces tests sortingviaux, peut-être qu’ils seraient plus précieux. Cela dépend vraiment de votre configuration de test et de la nature de l’application. Si la remise est importante pour l’application, vous allez de toute façon attraper des bogues dans cette méthode lors des tests fonctionnels. Tous les tests unitaires vous permettent de les détecter au moment où vous testez cette unité, lorsque l’emplacement de l’erreur est immédiatement évident, au lieu d’attendre que l’application soit intégrée et que l’emplacement de l’erreur soit moins évident.

Au fait, personnellement, je n’utiliserais pas 100 comme prix dans le scénario de test (ou plutôt, si je le faisais, j’appendais un autre test avec un autre prix). La raison en est que quelqu’un à l’avenir pourrait penser que Discount est censé être un pourcentage. L’un des objectives des tests sortingviaux comme celui-ci est de s’assurer que les erreurs de lecture de la spécification sont corrigées.

[Concernant l’édition: je pense qu’il est inévitable qu’une spécification incorrecte soit un sharepoint défaillance. Si vous ne savez pas ce que l’application est censée faire, il y a des chances qu’elle ne le fasse pas. Mais écrire des tests pour refléter la spécification n’amplifie pas ce problème, mais ne parvient pas à le résoudre. Donc, vous n’ajoutez pas de nouveaux points de défaillance, vous représentez simplement les erreurs existantes dans le code au lieu de la documentation de gaufre .]

Tout ce que je vois est des points de défaillance plus possibles, sans retour bénéfique réel, si le prix de la remise est erroné, l’équipe de test trouvera toujours le problème, comment les tests unitaires ont-ils sauvé du travail?

Les tests unitaires ne sont pas vraiment censés sauver du travail, ils sont supposés vous aider à trouver et à prévenir les bogues. C’est plus de travail, mais c’est le bon type de travail. Il s’agit de réfléchir à votre code aux niveaux de granularité les plus bas et d’écrire des cas de test qui prouvent qu’il fonctionne dans les conditions attendues , pour un ensemble donné d’entrées. Il isole les variables afin de gagner du temps en regardant au bon endroit quand un bogue se présente. Il enregistre cette suite de tests afin de pouvoir les utiliser encore et encore lorsque vous devez apporter des modifications.

Personnellement, je pense que la plupart des méthodologies ne sont pas très éloignées de l’ ingénierie logicielle cargo , TDD inclus, mais vous n’avez pas à respecter les exigences ssortingctes de TDD pour tirer parti des tests unitaires. Conservez les bonnes pièces et jetez les pièces qui ne rapportent pas grand chose.

Enfin, la réponse à votre question titrée ” Comment testez-vous un test unitaire? ” Est que vous ne devriez pas avoir à le faire. Chaque test unitaire doit être simple et sans cervelle. Appelez une méthode avec une entrée spécifique et comparez-la à la sortie attendue. Si la spécification d’une méthode change, vous pouvez vous attendre à ce que certains tests unitaires de cette méthode doivent également être modifiés. C’est l’une des raisons pour lesquelles vous effectuez des tests unitaires à un niveau de granularité si bas, de sorte que seuls certains tests unitaires doivent être modifiés. Si vous constatez que des tests pour plusieurs méthodes différentes changent pour un changement dans une exigence, vous ne testez peut-être pas le niveau de granularité requirejs.

Les tests unitaires sont là pour que vos unités (méthodes) fassent ce que vous attendez. L’écriture du test vous oblige d’abord à réfléchir à ce que vous attendez avant d’écrire le code. Penser avant de faire est toujours une bonne idée.

Les tests unitaires doivent refléter les règles métier. Certes, il peut y avoir des erreurs dans le code, mais l’écriture du test vous permet d’abord de l’écrire du sharepoint vue de la règle métier avant qu’un code ait été écrit. Je pense que l’écriture du test est plus susceptible de conduire à l’erreur que vous décrivez parce que vous savez comment le code l’implémente et que vous êtes simplement tenté de vous assurer que l’implémentation est correcte – pas que l’intention soit correcte.

De plus, les tests unitaires ne sont qu’une forme – et la plus faible à celle – des tests que vous devriez écrire. Les tests d’intégration et les tests d’acceptation doivent également être écrits, ces derniers par le client, si possible, pour s’assurer que le système fonctionne comme prévu. Si vous trouvez des erreurs lors de ce test, revenez en arrière et écrivez les tests unitaires (qui échouent) pour tester le changement de fonctionnalité pour le faire fonctionner correctement, puis changez votre code pour passer le test. Maintenant, vous avez des tests de régression qui capturent vos corrections de bogues.

[MODIFIER]

Une autre chose que j’ai trouvée avec TDD. Il force presque le bon design par défaut. En effet, les conceptions fortement couplées sont presque impossibles à tester isolément. L’utilisation de TDD ne tarde pas à comprendre que l’utilisation d’interfaces, l’inversion du contrôle et l’dependency injection – tous des modèles qui amélioreront votre conception et réduiront le couplage – sont vraiment importants pour le code testable.

Comment peut-on tester un test ? Le test de mutation est une technique précieuse que j’ai personnellement utilisée pour obtenir un effet surprenant. Lisez l’article lié pour plus de détails, et des liens vers des références encore plus académiques, mais en général, il “teste vos tests” en modifiant votre code source (en changeant “x + = 1” en “x – = 1” par exemple) relancer vos tests, en veillant à ce qu’au moins un test échoue. Toutes les mutations qui ne provoquent pas d’échec au test sont signalées pour une investigation ultérieure.

Vous seriez surpris de voir comment vous pouvez avoir une couverture 100% par ligne et par twig avec un ensemble de tests complets, et pourtant vous pouvez changer ou même commenter une ligne dans votre source sans que les tests soient plaintifs. Souvent, cela revient à ne pas tester avec les bons intrants pour couvrir tous les cas limites, parfois c’est plus subtil, mais dans tous les cas, j’ai été impressionné par le résultat.

Lors de l’application du développement piloté par les tests (TDD), on commence par un test défaillant . Cette étape, qui peut sembler inutile, est là pour vérifier que le test unitaire teste quelque chose. En effet, si le test n’échoue jamais, il n’apporte aucune valeur et, pire, conduit à une mauvaise confiance, car vous comptez sur un résultat positif qui ne prouve rien.

En suivant ssortingctement ce processus, toutes les unités sont protégées par le filet de sécurité que les tests unitaires effectuent, même les plus banals.

 Assert.IsEqual(p.DiscountPrice,90); 

Il n’y a pas de raison que le test évolue dans cette direction – ou il manque quelque chose dans votre raisonnement. Lorsque le prix est 100 et le rabais 20, le prix de la remise est 80. C’est comme un invariant.

Imaginez maintenant que votre logiciel doit prendre en charge un autre type de remise basé sur un pourcentage, peut-être que, selon le volume acheté, votre méthode Product :: DiscountPrice () pourrait devenir plus compliquée. Et il est possible que l’introduction de ces modifications rompt la règle de remise simple que nous avions initialement. Ensuite, vous verrez la valeur de ce test qui détectera immédiatement la régression.


Rouge – Vert – Refactor – c’est pour retenir l’essence du processus TDD.

Rouge fait référence à la barre rouge JUnit lorsqu’un test échoue.

Le vert est la couleur de la barre de progression de JUnit lorsque tous les tests réussissent.

Refactor sous condition verte: supprimez toute duplication, améliorez la lisibilité.


Maintenant, pour répondre à votre question sur les «3-4 couches au-dessus du code», ceci est vrai dans un processus traditionnel (en cascade), et non lorsque le processus de développement est agile. Et agile est le monde d’où vient TDD; TDD est la pierre angular de eXtreme Programming .

Agile concerne la communication directe plutôt que les documents exigés.

Alors que je suis tout pour les tests unitaires, je me demande parfois si cette forme de premier développement de test est vraiment bénéfique …

De petits tests sortingviaux comme celui-ci peuvent être le «canari dans la mine de charbon» pour votre base de code, alertant du danger avant qu’il ne soit trop tard. Les tests sortingviaux sont utiles car ils vous aident à bien comprendre les interactions.

Par exemple, pensez à un test sortingvial mis en place pour déterminer comment utiliser une API avec laquelle vous n’êtes pas familier. Si ce test a un rapport avec ce que vous faites dans le code qui utilise l’API “pour de vrai”, il est utile de conserver ce test. Lorsque l’API libère une nouvelle version et que vous devez la mettre à niveau. Vous avez maintenant vos hypothèses sur la manière dont l’API doit se comporter enregistré dans un format exécutable que vous pouvez utiliser pour intercepter des régressions.

… Dans un processus réel, vous avez 3 à 4 couches au-dessus de votre code (demande commerciale, document d’exigences, document d’architecture), où la règle métier définie (prix d’escompte est remise) peut être mal définie. Si c’est le cas, votre test unitaire ne vous dit rien.

Si vous avez codé pendant des années sans écrire de test, il ne sera peut-être pas évident pour vous qu’il y a de la valeur. Mais si vous pensez que la meilleure façon de travailler est la “sortie anticipée, la publication fréquente” ou “agile”, dans la mesure où vous souhaitez pouvoir déployer rapidement / continuellement, votre test signifie certainement quelque chose. La seule façon de le faire est de légitimer chaque modification apscope au code avec un test. Peu importe la taille du test, une fois que vous avez une suite de tests verte, vous pouvez théoriquement le déployer. Voir aussi “production continue” et “bêta perpétuel”.

Vous ne devez pas non plus être le premier à être de cet état d’esprit, mais c’est généralement le moyen le plus efficace d’y arriver. Lorsque vous effectuez un TDD, vous vous enfermez dans un petit cycle de deux à trois minutes. Vous ne pouvez à aucun moment vous arrêter et partir et avoir un désordre complet sur vos mains qui prendra une heure pour le déboguer et le remettre ensemble.

De plus, votre test unitaire est un autre point d’échec …

Un test réussi est un test qui démontre une défaillance du système. Un test défaillant vous avertira d’une erreur dans la logique du test ou dans la logique de votre système. Le but de vos tests est de briser votre code ou de prouver qu’un scénario fonctionne.

Si vous écrivez des tests après le code, vous courez le risque d’écrire un test qui est “mauvais” car pour que votre test fonctionne vraiment, vous devez le voir à la fois cassé et fonctionnel. Lorsque vous écrivez des tests après le code, cela signifie que vous devez “lancer le piège” et introduire un bogue dans le code pour voir le test échouer. La plupart des développeurs ne sont pas seulement inquiets à ce sujet, mais pensent que c’est une perte de temps.

Que gagnons-nous ici?

Il y a certainement un avantage à faire les choses de cette façon. Michael Feathers définit “code hérité” comme “code non testé”. Lorsque vous adoptez cette approche, vous légitimez chaque modification apscope à votre base de code. C’est plus rigoureux que de ne pas utiliser de tests, mais quand il s’agit de maintenir une base de code volumineuse, c’est rentable.

En parlant de plumes, il y a deux excellentes ressources que vous devriez vérifier à ce sujet:

  • Travailler efficacement avec Legacy Code
  • Développement d’applications Brownfield dans .NET

Les deux expliquent comment utiliser ces types de pratiques et de disciplines dans des projets qui ne sont pas “Greenfield”. Ils fournissent des techniques pour écrire des tests sur des composants étroitement couplés, des dépendances câblées et des éléments dont vous n’avez pas nécessairement le contrôle. Il s’agit de trouver des “coutures” et des tests autour de ceux-ci.

[I] Si le prix de la remise est incorrect, l’équipe de test trouvera toujours le problème, comment les tests unitaires ont-ils sauvé du travail?

Des habitudes comme celles-ci sont comme un investissement. Les retours ne sont pas immédiats; ils s’accumulent avec le temps. L’alternative à la non-vérification consiste essentiellement à ne pas être capable d’attraper des régressions, à introduire du code sans crainte d’erreurs d’intégration ou à prendre des décisions de conception. La beauté est de légitimer chaque changement introduit dans votre base de code.

Qu’est-ce que j’oublie ici? S’il vous plaît apprenez-moi à aimer TDD, car j’ai du mal à l’accepter comme utile jusqu’à présent. Je veux aussi, parce que je veux restr progressiste, mais cela n’a tout simplement aucun sens pour moi.

Je le considère comme une responsabilité professionnelle. C’est un idéal à atteindre. Mais c’est très difficile à suivre et fastidieux. Si vous vous en souciez, et que vous estimez que vous ne devriez pas produire de code qui n’est pas testé, vous serez en mesure de trouver la volonté d’apprendre de bonnes habitudes de test. Une chose que je fais beaucoup maintenant (comme les autres), c’est de me donner une heure pour écrire du code sans aucun test, puis avoir la discipline nécessaire pour le jeter. Cela peut sembler inutile, mais ce n’est pas vraiment le cas. Ce n’est pas comme si cet exercice coûtait du matériel physique à une entreprise. Cela m’a aidé à comprendre le problème et à écrire du code de manière à ce qu’il soit à la fois de meilleure qualité et testable.

Mon conseil serait finalement que si vous n’avez vraiment pas envie d’y être bon, alors ne le faites pas du tout. Les mauvais tests qui ne sont pas maintenus, ne donnent pas de bons résultats, etc. peuvent être pires que de ne pas avoir de tests. Il est difficile d’apprendre par vous-même, et vous ne l’aimerez probablement pas, mais il sera presque impossible d’apprendre si vous n’avez pas envie de le faire ou si vous ne voyez pas assez de valeur pour le faire. justifier l’investissement dans le temps.

Quelques personnes ont mentionné que les tests aident à appliquer les spécifications. D’après mon expérience, la spécification s’est également trompée, le plus souvent …

Un clavier de développeur est l’endroit où le caoutchouc rencontre la route. Si la spécification est erronée et que vous ne lèvez pas le drapeau, il est fort probable que vous soyez blâmé. Ou au moins votre code le fera. La discipline et la rigueur dans les tests sont difficiles à respecter. Ce n’est pas du tout facile. Il faut de la pratique, beaucoup d’apprentissage et beaucoup d’erreurs. Mais finalement, cela porte ses fruits. Sur un projet rapide qui change rapidement, c’est la seule façon de dormir la nuit, peu importe si cela vous ralentit.

Une autre chose à considérer ici est que les techniques qui sont fondamentalement les mêmes que les tests ont été prouvées pour fonctionner dans le passé: “salle blanche” et “conception par contrat” ​​ont tous deux tendance à produire les mêmes types de constructions “méta” les tests font, et imposent ceux à différents points. Aucune de ces techniques ne sont des puces d’argent, et la rigueur vous coûtera en fin de compte dans l’étendue des fonctionnalités que vous pouvez proposer en termes de délai de commercialisation. Mais ce n’est pas ce dont il s’agit. Il s’agit de pouvoir maintenir ce que vous livrez. Et c’est très important pour la plupart des projets.

Les tests unitaires fonctionnent de manière très similaire à la comptabilité en partie double. Vous énoncez la même chose (règle métier) de deux manières très différentes (comme des règles programmées dans votre code de production et des exemples simples et représentatifs dans vos tests). Il est très peu probable que vous fassiez la même erreur dans les deux cas, alors si les deux sont d’accord, il est plutôt improbable que vous vous trompiez.

Comment les tests en valent-ils la peine? Dans mon expérience d’au moins quatre façons, du moins lors du développement axé sur les tests:

  • cela vous aide à concevoir un design bien découplé. Vous ne pouvez qu’unifier le code de test qui est bien découplé;
  • cela vous aide à déterminer quand vous avez terminé. Avoir à spécifier le comportement nécessaire dans les tests permet de ne pas créer des fonctionnalités dont vous n’avez pas réellement besoin et de déterminer à quel moment les fonctionnalités sont terminées.
  • cela vous donne un filet de sécurité pour les refactorisations, ce qui rend le code beaucoup plus sensible aux changements; et
  • cela vous évite beaucoup de temps de débogage, ce qui est extrêmement coûteux (j’ai entendu dire que traditionnellement, les développeurs consacraient jusqu’à 80% de leur temps au débogage).

La plupart des tests unitaires, des hypothèses de test. Dans ce cas, le prix de remise devrait être le prix moins la remise. Si vos hypothèses sont fausses, je parie que votre code est également faux. Et si vous faites une erreur stupide, le test échouera et vous le corrigerez.

Si les règles changent, le test échouera et c’est une bonne chose. Il faut donc aussi changer le test dans ce cas.

En règle générale, si un test échoue tout de suite (et que vous n’utilisez pas le premier test), le test ou le code est incorrect (ou les deux si vous rencontrez une mauvaise journée). Vous utilisez le bon sens (et possilby par les spécifications) pour corriger le code incriminé et relancer le test.

Comme l’a dit Jason, le test est la sécurité. Et oui, ils introduisent parfois du travail supplémentaire à cause de tests défectueux. Mais la plupart du temps, ils économisent beaucoup de temps. (Et vous avez l’occasion parfaite de punir le type qui casse le test (nous parlons de poulet en caoutchouc)).

Testez tout ce que vous pouvez. Même des erreurs insignifiantes, comme oublier de convertir les mètres en pieds, peuvent avoir des effets secondaires très coûteux. Écrivez un test, écrivez le code pour le vérifier, faites-le passer, continuez. Qui sait à un moment donné, quelqu’un peut changer le code de réduction. Un test peut détecter le problème.

Je vois les tests unitaires et le code de production comme ayant une relation symbiotique. Autrement dit: l’un teste l’autre. Et les deux testent le développeur.

Rappelez-vous que le coût de la réparation des défauts augmente (de manière exponentielle) à mesure que les défauts traversent le cycle de développement. Oui, l’équipe de test pourrait détecter le défaut, mais il faudra (généralement) plus de travail pour isoler et corriger le défaut à partir de ce moment que si un test unitaire avait échoué, et il serait plus facile d’introduire d’autres défauts ne pas avoir de tests unitaires à exécuter.

C’est généralement plus facile à voir avec quelque chose de plus qu’un exemple sortingvial … et avec des exemples sortingviaux, eh bien, si vous échouez d’une manière ou d’une autre au test unitaire, la personne qui l’examine détectera l’erreur dans le test ou tous les deux. (Ils sont en cours de révision, n’est-ce pas?) Comme le souligne tvanfosson , les tests unitaires ne sont qu’une partie d’un plan SQA.

Dans un sens, les tests unitaires sont une assurance. Ils ne garantissent pas que vous attraperez tous les défauts, et il peut parfois sembler que vous y consacrez beaucoup de ressources, mais quand ils détectent des défauts que vous pouvez corriger, vous dépenserez beaucoup moins. que si vous n’aviez eu aucun test et que vous deviez corriger tous les défauts en aval.

Je vois votre argument, mais il est clairement exagéré.

Votre argument est essentiellement le suivant: les tests introduisent une défaillance. Par conséquent, les tests sont mauvais / perte de temps.

Bien que cela puisse être vrai dans certains cas, ce n’est guère la majorité.

TDD suppose: Plus de tests = moins d’échec.

Les tests sont plus susceptibles de détecter les points de défaillance que de les introduire.

Encore plus d’automatisation peut aider ici! Oui, écrire des tests unitaires peut être très compliqué, alors utilisez des outils pour vous aider. Jetez un oeil à quelque chose comme Pex, de Microsoft, si vous utilisez .Net. Il créera automatiquement des suites de tests unitaires en examinant votre code. Il va arriver avec des tests qui donnent une bonne couverture, en essayant de couvrir tous les chemins à travers votre code.

Bien sûr, en regardant simplement votre code, il ne peut pas savoir ce que vous essayez réellement de faire, donc il ne sait pas si c’est correct ou non. Mais, cela générera des cas de tests intéressants pour vous, et vous pourrez ensuite les examiner et voir si cela se comporte comme vous le souhaitez.

Si vous allez ensuite plus loin et écrivez des tests unitaires paramétrés (vous pouvez vraiment les considérer comme des contrats), cela générera des cas de tests spécifiques, et cette fois-ci, vous pourrez savoir si quelque chose ne va pas.

J’ai réfléchi un peu à la manière de répondre à cette question et souhaite faire un parallèle avec la méthode scientifique. IMO, vous pouvez reformuler cette question, “Comment expérimentez-vous une expérience?”

Des expériences vérifient des hypothèses empiriques (hypothèses) sur l’univers physique. Les tests unitaires testeront les hypothèses concernant l’état ou le comportement du code qu’ils appellent. Nous pouvons parler de la validité d’une expérience, mais c’est parce que nous soaps, grâce à de nombreuses autres expériences, que quelque chose ne va pas. Il n’a pas à la fois une validité convergente et une preuve empirique . Nous ne concevons pas une nouvelle expérience pour tester ou vérifier la validité d’ une expérience , mais nous pouvons concevoir une expérience complètement nouvelle .

Donc, comme pour les expériences , nous ne décrivons pas la validité d’un test unitaire selon qu’il réussit ou non un test unitaire. Avec d’autres tests unitaires, il décrit les hypothèses que nous faisons sur le système qu’il teste. De même, comme les expériences, nous essayons de supprimer autant de complexité que possible de ce que nous testons. “Aussi simple que possible, mais pas plus simple.”

Contrairement aux expériences , nous avons une astuce pour vérifier que nos tests sont valides, à part la validité convergente. Nous pouvons intelligemment introduire un bogue qui devrait être détecté par le test et voir si le test échoue effectivement. (Si seulement nous pouvions le faire dans le monde réel, nous dépendrions beaucoup moins de cette validité convergente!) Une manière plus efficace de le faire est de regarder votre test échouer avant de l’implémenter (le pas rouge dans Rouge, Vert, Refactor) ).

Vous devez utiliser le bon paradigme lors de la rédaction des tests.

  1. Commencez par écrire d’abord vos tests.
  2. Assurez-vous qu’ils ne commencent pas avec.
  3. Faites-les passer.
  4. Révision du code avant de vérifier votre code (assurez-vous que les tests sont examinés)

Vous ne pouvez pas toujours être sûr mais ils améliorent les tests globaux.

Même si vous ne testez pas votre code, il sera sûrement testé en production par vos utilisateurs. Les utilisateurs sont très créatifs en essayant de faire planter votre logiciel et de trouver même des erreurs non critiques.

La résolution des bogues en production est beaucoup plus coûteuse que la résolution des problèmes en phase de développement. Comme effet secondaire, vous perdrez des revenus en raison d’un exode de clients. Vous pouvez compter sur 11 clients perdus ou non gagnés pour 1 client en colère.