Qu’est-ce que les tests unitaires ?

https://stackoverflow.com/questions/1383

08-06-2019
|

Question

J'ai vu de nombreuses questions demandant « comment » effectuer des tests unitaires dans une langue spécifique, mais aucune question demandant « quoi », « pourquoi » et « quand ».

Qu'est-ce que c'est?
Que fait-il pour moi?
Pourquoi devrais-je l'utiliser ?
Quand dois-je l’utiliser (et quand non) ?
Quels sont les pièges et idées fausses courants

La solution

Les tests unitaires consistent, en gros, à tester des bits de votre code isolément avec le code de test.Les avantages immédiats qui me viennent à l’esprit sont :

L'exécution des tests devient automatisable et reproductible
Vous pouvez tester à un niveau beaucoup plus granulaire que les tests pointer-cliquer via une interface graphique

Notez que si votre code de test écrit dans un fichier, ouvre une connexion à une base de données ou effectue quelque chose sur le réseau, il est plus approprié de le classer comme un test d'intégration.Les tests d'intégration sont une bonne chose, mais ne doivent pas être confondus avec les tests unitaires.Le code du test unitaire doit être court, simple et rapide à exécuter.

Une autre façon d’envisager les tests unitaires consiste à écrire les tests en premier.C'est ce qu'on appelle le développement piloté par les tests (TDD en abrégé).TDD apporte des avantages supplémentaires :

Vous n'écrivez pas de code spéculatif "Je pourrais en avoir besoin dans le futur" -- juste assez pour que les tests réussissent
Le code que vous avez écrit est toujours couvert par des tests
En écrivant d'abord le test, vous êtes obligé de réfléchir à la manière dont vous souhaitez appeler le code, ce qui améliore généralement la conception du code à long terme.

Si vous ne faites pas de tests unitaires maintenant, je vous recommande de vous y lancer.Procurez-vous un bon livre, pratiquement n'importe quel livre xUnit fera l'affaire car les concepts sont très transférables entre eux.

Parfois, écrire des tests unitaires peut être pénible.Lorsque cela arrive, essayez de trouver quelqu'un pour vous aider et résistez à la tentation de « simplement écrire ce foutu code ».Les tests unitaires, c'est un peu comme faire la vaisselle.Ce n'est pas toujours agréable, mais cela garde votre cuisine métaphorique propre, et vous voulez vraiment qu'elle soit propre.:)

Modifier:Une idée fausse me vient à l’esprit, même si je ne suis pas sûr qu’elle soit si courante.J'ai entendu un chef de projet dire que les tests unitaires obligeaient l'équipe à écrire tout le code deux fois.Si cela ressemble à cela, eh bien, vous vous trompez.Non seulement l'écriture des tests accélère généralement le développement, mais elle vous donne également un indicateur pratique « maintenant, j'ai terminé » que vous n'auriez pas autrement.

Autres conseils

Je ne suis pas en désaccord avec Dan (même si un meilleur choix serait peut-être de ne pas répondre)... mais...

Les tests unitaires sont le processus d'écriture de code pour tester le comportement et les fonctionnalités de votre système.

Évidemment, les tests améliorent la qualité de votre code, mais ce n'est qu'un avantage superficiel des tests unitaires.Les vrais avantages sont les suivants :

Facilitez le changement d'implémentation technique tout en vous assurant de ne pas modifier le comportement (refactoring).Un code correctement testé unitaire peut être refactorisé/nettoyé de manière agressive avec peu de chances de casser quoi que ce soit sans le remarquer.
Donnez confiance aux développeurs lorsqu’ils ajoutent un comportement ou apportent des correctifs.
Documentez votre code
Indiquez les zones de votre code qui sont étroitement liées.Il est difficile de tester unitairement un code étroitement couplé
Fournissez un moyen d'utiliser votre API et recherchez les difficultés dès le début
Indique des méthodes et des classes peu cohérentes

Vous devez effectuer des tests unitaires car il est dans votre intérêt de fournir un produit maintenable et de qualité à votre client.

Je vous suggère de l'utiliser pour tout système, ou partie de système, qui modélise le comportement du monde réel.En d’autres termes, il est particulièrement adapté au développement des entreprises.Je ne l'utiliserais pas pour des programmes jetables/utilitaires.Je ne l'utiliserais pas pour des parties d'un système dont le test est problématique (l'interface utilisateur est un exemple courant, mais ce n'est pas toujours le cas)

Le plus grand écueil est que les développeurs testent une unité trop grande ou considèrent une méthode comme une unité.C'est particulièrement vrai si vous ne comprenez pas Inversion de contrôle - auquel cas vos tests unitaires se transformeront toujours en tests d'intégration de bout en bout.Les tests unitaires doivent tester les comportements individuels – et la plupart des méthodes ont de nombreux comportements.

La plus grande idée fausse est que les programmeurs ne devraient pas tester.Seuls les programmeurs mauvais ou paresseux le croient.Le constructeur de votre toit ne devrait-il pas le tester ?Le médecin qui remplace une valvule cardiaque ne devrait-il pas tester la nouvelle valvule ?Seul un programmeur peut vérifier que son code fait ce qu'il avait prévu de faire (le contrôle qualité peut tester les cas extrêmes - comment le code se comporte lorsqu'on lui demande de faire des choses que le programmeur n'avait pas prévu, et le client peut effectuer un test d'acceptation - le code fait-il ce que le client a payé pour cela)

La principale différence entre les tests unitaires et le fait de « simplement ouvrir un nouveau projet et tester ce code spécifique » est qu'il s'agit de automatique, ainsi répétable.

Si vous testez votre code manuellement, cela peut vous convaincre que le code fonctionne parfaitement - dans son état actuel.Mais qu’en est-il une semaine plus tard, lorsque vous y avez apporté une légère modification ?Êtes-vous prêt à le retester à la main à chaque fois rien des changements dans votre code ?Probablement pas :-(

Mais si tu peux lancez vos tests à tout moment, d'un simple clic, exactement de la même manière, en quelques secondes, puis ils volonté vous montrer immédiatement chaque fois que quelque chose est cassé.Et si vous intégrez également les tests unitaires dans votre processus de construction automatisé, ils vous alerteront des bogues même dans les cas où un changement apparemment totalement indépendant a cassé quelque chose dans une partie éloignée de la base de code - alors qu'il ne vous viendrait même pas à l'esprit qu'il y a un besoin de retester cette fonctionnalité particulière.

C'est le principal avantage des tests unitaires par rapport aux tests manuels.Mais attendez, il y a plus :

tests unitaires raccourcir la boucle de rétroaction sur le développement dramatiquement :avec un service de test distinct, cela peut prendre des semaines pour que vous sachiez qu'il y a un bug dans votre code, après quoi vous avez déjà oublié une grande partie du contexte, cela peut donc vous prendre des heures pour trouver et corriger le bug ;OTOH avec les tests unitaires, le cycle de retour d'information est mesuré en secondes et le processus de correction de bugs s'apparente généralement à un "oh merde, j'ai oublié de vérifier cette condition ici" :-)
tests unitaires efficaces document (votre compréhension du) comportement de votre code
les tests unitaires vous obligent à réévaluer vos choix de conception, ce qui entraîne conception plus simple et plus propre

Les frameworks de tests unitaires, à leur tour, vous facilitent l'écriture et l'exécution de vos tests.

On ne m'a jamais enseigné les tests unitaires à l'université et il m'a fallu un certain temps pour les « comprendre ».J'ai lu quelque chose à ce sujet, je me suis dit "ah, d'accord, les tests automatisés, ça pourrait être cool, je suppose", puis je l'ai oublié.

Il m'a fallu un peu plus de temps avant de vraiment comprendre le problème :Disons que vous travaillez sur un grand système et que vous écrivez un petit module.Il compile, vous le mettez à l’épreuve, il fonctionne très bien, vous passez à la tâche suivante.Neuf mois plus tard et deux versions plus tard, quelqu'un d'autre apporte des modifications à certaines apparemment partie sans rapport du programme, et cela casse le module.Pire encore, ils testent leurs modifications et leur code fonctionne, mais ils ne testent pas votre module ;bon sang, ils ne connaissent peut-être même pas votre module existe.

Et maintenant tu as un problème :un code cassé est dans le coffre et personne ne le sait.Le meilleur des cas est qu'un testeur interne le trouve avant l'expédition, mais corriger le code tard dans le jeu coûte cher.Et si aucun testeur interne ne le trouve... eh bien, cela peut effectivement coûter très cher.

La solution réside dans les tests unitaires.Ils détecteront des problèmes lorsque vous écrivez du code - ce qui est bien - mais vous auriez pu le faire à la main.La véritable récompense est qu'ils détecteront les problèmes neuf mois plus tard, alors que vous travaillez maintenant sur un projet complètement différent, mais un stagiaire d'été pense que cela semblerait plus ordonné si ces paramètres étaient classés par ordre alphabétique - et ensuite le test unitaire vous avez écrit il y a longtemps échoue, et quelqu'un jette des choses au stagiaire jusqu'à ce qu'il modifie l'ordre des paramètres. C'est le « pourquoi » des tests unitaires.:-)

En parlant des avantages philosophiques des tests unitaires et du TDD, voici quelques-unes des observations clés "d'ampoule" qui m'ont frappé lors de mes premiers pas hésitants sur la route de l'illumination du TDD (aucune originale ni nécessairement d'actualité)...

TDD ne signifie PAS écrire deux fois plus de code.Le code de test est généralement assez rapide et indolore à écrire et constitue un élément clé et essentiel de votre processus de conception.
TDD vous aide à comprendre quand arrêter de coder !Vos tests vous donnent l’assurance que vous en avez fait assez pour le moment et que vous pouvez arrêter de peaufiner et passer à autre chose.
Les tests et le code fonctionnent ensemble pour obtenir un meilleur code.Votre code pourrait être mauvais/bogué.Votre TEST pourrait être mauvais/bogué.Dans TDD, vous comptez sur les chances que les DEUX soient mauvais/bogués étant assez faibles.C'est souvent le test qui doit être corrigé, mais cela reste un bon résultat.
TDD aide à coder la constipation.Vous connaissez ce sentiment que vous avez tellement de choses à faire et que vous savez à peine par où commencer ?C'est vendredi après-midi, si vous tergiversez encore quelques heures...TDD vous permet d'étoffer très rapidement ce que vous pensez devoir faire et de faire avancer votre codage rapidement.De plus, comme les rats de laboratoire, je pense que nous réagissons tous à ce grand feu vert et travaillons plus dur pour le revoir !
Dans la même veine, ces types de designers peuvent VOIR sur quoi ils travaillent.Ils peuvent s'éloigner pour une pause jus/cigarette/iphone et revenir à un moniteur qui leur donne immédiatement un repère visuel quant à l'endroit où ils sont arrivés.TDD nous donne quelque chose de similaire.Il est plus facile de voir où nous en sommes lorsque la vie intervient...
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 là où je pense qu'ils seront les plus utiles même si le reste de ma couverture de code est malheureusement incomplet.
TDD aide de toutes sortes de manières surprenantes sur toute la ligne.De bons tests unitaires peuvent aider à documenter ce que quelque chose est censé faire, ils peuvent vous aider à migrer le code d'un projet à un autre et vous donner un sentiment injustifié de supériorité sur vos collègues non-testeurs :)

Cette présentation est une excellente introduction à tous les délicieux tests de qualité qu'impliquent.

Je voudrais recommander le livre xUnit Testing Patterns de Gerard Meszaros.Il est volumineux mais constitue une excellente ressource sur les tests unitaires.Voici un lien vers son site Web où il discute des bases des tests unitaires. http://xunitpatterns.com/XUnitBasics.html

J'utilise des tests unitaires pour gagner du temps.

Lors de la création d'une logique métier (ou d'un accès aux données), les fonctionnalités de test peuvent souvent impliquer de saisir des éléments sur de nombreux écrans qui peuvent ou non être encore terminés.L'automatisation de ces tests permet de gagner du temps.

Pour moi, les tests unitaires sont une sorte de harnais de tests modularisé.Il existe généralement au moins un test par fonction publique.J'écris des tests supplémentaires pour couvrir divers comportements.

Tous les cas particuliers auxquels vous avez pensé lors du développement du code peuvent être enregistrés dans le code lors des tests unitaires.Les tests unitaires deviennent également une source d'exemples sur la façon d'utiliser le code.

Il est beaucoup plus rapide pour moi de découvrir que mon nouveau code casse quelque chose dans mes tests unitaires, puis d'archiver le code et de demander à un développeur front-end de trouver un problème.

Pour les tests d'accès aux données, j'essaie d'écrire des tests qui n'ont aucun changement ou qui se nettoient après eux-mêmes.

Les tests unitaires ne pourront pas répondre à toutes les exigences de test.Ils pourront gagner du temps de développement et tester les parties essentielles de l’application.

C'est mon point de vue.Je dirais que les tests unitaires sont la pratique consistant à écrire des tests logiciels pour vérifier que votre vrai logiciel fait ce qu'il est censé faire.Cela a commencé avec jUnit dans le monde Java et est également devenu une bonne pratique en PHP avec Test simple et phpUnité.Il s'agit d'une pratique fondamentale d'Extreme Programming et vous aide à être sûr que votre logiciel fonctionne toujours comme prévu après l'édition.Si vous disposez d'une couverture de test suffisante, vous pouvez effectuer une refactorisation majeure, corriger des bogues ou ajouter des fonctionnalités rapidement avec beaucoup moins de crainte d'introduire d'autres problèmes.

C'est plus efficace lorsque tous les tests unitaires peuvent être exécutés automatiquement.

Les tests unitaires sont généralement associés au développement OO.L'idée de base est de créer un script qui configure l'environnement de votre code puis l'exerce ;vous écrivez des assertions, spécifiez le résultat prévu que vous devez recevoir, puis exécutez votre script de test à l'aide d'un framework tel que ceux mentionnés ci-dessus.

Le framework exécutera tous les tests sur votre code, puis signalera le succès ou l'échec de chaque test.phpUnit est exécuté par défaut à partir de la ligne de commande Linux, bien que des interfaces HTTP soient disponibles pour cela.SimpleTest est basé sur le Web par nature et est beaucoup plus facile à mettre en œuvre, IMO.En combinaison avec xDebug, phpUnit peut vous fournir des statistiques automatisées sur la couverture du code que certaines personnes trouvent très utiles.

Certaines équipes écrivent des hooks à partir de leur référentiel Subversion afin que les tests unitaires soient exécutés automatiquement chaque fois que vous validez des modifications.

C'est une bonne pratique de conserver vos tests unitaires dans le même référentiel que votre application.

Les bibliothèques aiment NUnité, xUnité ou JUnit sont juste obligatoires si vous souhaitez développer vos projets en utilisant le TDD approche popularisée par Kent Beck :

Tu peux lire Introduction au développement piloté par les tests (TDD) ou le livre de Kent Beck Développement piloté par les tests :Par exemple.

Ensuite, si vous voulez être sûr que vos tests couvrent une « bonne » partie de votre code, vous pouvez utiliser des logiciels comme Couverture, JCouverture, Couverture de pièce ou peu importe.Ils vous indiqueront le pourcentage de couverture de votre code.En fonction de votre maîtrise du TDD, vous saurez si vous l'avez suffisamment bien pratiqué :)

Les tests unitaires consistent à tester une unité de code (par ex.une seule fonction) sans avoir besoin de l'infrastructure sur laquelle repose cette unité de code.c'est à dire.testez-le isolément.

Si, par exemple, la fonction que vous testez se connecte à une base de données et effectue une mise à jour, dans un test unitaire, vous ne souhaiterez peut-être pas effectuer cette mise à jour.Vous le feriez s’il s’agissait d’un test d’intégration mais dans ce cas ce n’est pas le cas.

Ainsi, un test unitaire exercerait la fonctionnalité incluse dans la « fonction » que vous testez sans effets secondaires de la mise à jour de la base de données.

Supposons que votre fonction récupère certains nombres d'une base de données, puis effectue un calcul d'écart type.Qu'essayez-vous de tester ici ?Que l'écart type est calculé correctement ou que les données sont renvoyées depuis la base de données ?

Dans un test unitaire, vous souhaitez simplement tester que l'écart type est calculé correctement.Dans un test d'intégration, vous souhaitez tester le calcul de l'écart type et la récupération de la base de données.

Les tests unitaires consistent à écrire du code qui teste le code de votre application.

Le Unité une partie du nom concerne l'intention de tester de petites unités de code (une méthode par exemple) à la fois.

xUnit est là pour vous aider dans ces tests - ce sont des frameworks qui vous aident.Une partie de cela réside dans les exécuteurs de tests automatisés qui vous indiquent quels tests échouent et lesquels réussissent.

Ils disposent également de fonctionnalités permettant de configurer au préalable le code commun dont vous avez besoin dans chaque test et de le supprimer une fois tous les tests terminés.

Vous pouvez effectuer un test pour vérifier qu'une exception attendue a été levée, sans avoir à écrire vous-même l'intégralité du bloc try catch.

Je pense que ce que vous ne comprenez pas, c'est que les frameworks de tests unitaires comme NUnit (et autres) vous aideront dans automatisation tests de petite à moyenne taille.Habituellement, vous pouvez exécuter les tests dans une interface graphique (c'est le cas avec NUnité, par exemple) en cliquant simplement sur un bouton, puis - espérons-le - voir la barre de progression rester verte.S'il devient rouge, le framework vous montre quel test a échoué et ce qui n'a pas fonctionné exactement.Dans un test unitaire normal, vous utilisez souvent des assertions, par ex. Assert.AreEqual(expectedValue, actualValue, "some description") - donc si les deux valeurs sont inégales, vous verrez une erreur disant "une description :attendu <expectedValue> mais était <actualValue>".

En conclusion, les tests unitaires rendront les tests plus rapides et beaucoup plus confortables pour les développeurs.Vous pouvez exécuter tous les tests unitaires avant de valider un nouveau code afin de ne pas interrompre le processus de construction des autres développeurs sur le même projet.

Utiliser Testivus.Tout ce que vous devez savoir est là :)

Les tests unitaires sont une pratique permettant de s'assurer que la fonction ou le module que vous allez implémenter se comportera comme prévu (exigences) et également de s'assurer de son comportement dans des scénarios tels que des conditions aux limites et des entrées non valides.

xUnité, NUnité, mbUnit, etc.sont des outils qui vous aident à rédiger les tests.

Le développement piloté par les tests a en quelque sorte repris le terme test unitaire.En tant qu'ancien, je mentionnerai la définition la plus générique de celui-ci.

Le test unitaire signifie également tester un seul composant dans un système plus grand.Ce composant unique peut être une DLL, un exe, une bibliothèque de classes, etc.Il pourrait même s'agir d'un système unique dans une application multi-système.Ainsi, en fin de compte, le test unitaire finit par tester ce que vous voulez appeler une seule pièce d'un système plus vaste.

Vous passerez ensuite aux tests intégrés ou système en testant la façon dont tous les composants fonctionnent ensemble.

Tout d'abord, qu'il s'agisse de tests unitaires ou de tout autre type de test automatisé (test d'intégration, de chargement, d'interface utilisateur, etc.), la principale différence par rapport à ce que vous suggérez est qu'il est automatisé, reproductible et qu'il ne nécessite aucune ressource humaine. à consommer (= personne ne doit effectuer les tests, ils s'exécutent généralement en appuyant sur un bouton).

Je suis allé à une présentation sur les tests unitaires à FoxForward 2007 et on m'a dit de ne jamais tester unitairement quoi que ce soit qui fonctionne avec des données.Après tout, si vous testez sur des données réelles, les résultats sont imprévisibles, et si vous ne testez pas sur des données réelles, vous ne testez pas réellement le code que vous avez écrit.Malheureusement, c'est la majeure partie du codage que je fais ces jours-ci.:-)

J'ai récemment essayé TDD lorsque j'écrivais une routine pour enregistrer et restaurer les paramètres.Tout d’abord, j’ai vérifié que je pouvais créer l’objet de stockage.Ensuite, il y avait la méthode dont j'avais besoin pour appeler.Alors, c'est ce que je pourrais appeler ça.Ensuite, je pourrais lui transmettre des paramètres.Ensuite, je pourrais lui transmettre des paramètres spécifiques.Et ainsi de suite, jusqu'à ce que je vérifie enfin qu'il enregistrerait le paramètre spécifié, me permettrait de le modifier, puis de le restaurer, pour plusieurs syntaxes différentes.

Je ne suis pas allé jusqu'au bout, parce que j'avais besoin de la routine maintenant, bon sang, mais c'était un bon exercice.

Que faites-vous si on vous donne un tas de conneries et que vous avez l'impression d'être coincé dans un état de nettoyage perpétuel dont vous savez qu'avec l'ajout de toute nouvelle fonctionnalité ou de tout nouveau code, cela peut briser l'ensemble actuel car le logiciel actuel est comme une maison de cartes?

Comment pouvons-nous alors faire des tests unitaires ?

Vous commencez petit.Le projet dans lequel je viens de me lancer n'avait pas de tests unitaires jusqu'à il y a quelques mois.Lorsque la couverture était si faible, nous choisissions simplement un fichier qui n'avait aucune couverture et cliquions sur « Ajouter des tests ».

À l’heure actuelle, nous en sommes à plus de 40 % et nous avons réussi à cueillir la plupart des fruits les plus faciles à trouver.

(Le meilleur, c'est que même à ce faible niveau de couverture, nous avons déjà rencontré de nombreux cas où le code faisait la mauvaise chose, et les tests l'ont détecté.C'est un énorme facteur de motivation pour pousser les gens à ajouter davantage de tests.)

Cela explique pourquoi vous devriez effectuer des tests unitaires.

Les 3 vidéos ci-dessous couvrent les tests unitaires en javascript, mais les principes généraux s'appliquent à la plupart des langages.

Tests unitaires :Les minutes actuelles permettront de gagner des heures plus tard - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

Tests unitaires JS (très bon) - https://www.youtube.com/watch?v=-IYqgx8JxlU

Écrire du JavaScript testable - https://www.youtube.com/watch?v=OzjogCFO4Zo

Maintenant, j'apprends juste sur le sujet, donc je n'ai peut-être pas raison à 100% et il y a plus que ce que je décris ici, mais ma compréhension de base des tests unitaires est que vous écrivez du code de test (qui est séparé de votre code principal) qui appelle une fonction dans votre code principal avec les entrées (arguments) requises par la fonction et le code vérifie ensuite s'il récupère une valeur de retour valide.S'il renvoie une valeur valide, le cadre de tests unitaires que vous utilisez pour exécuter les tests affiche un feu vert (tout va bien). Si la valeur n'est pas valide, vous obtenez un feu rouge et vous pouvez alors résoudre le problème immédiatement avant de publiez le nouveau code en production, sans tester, vous n'aurez peut-être pas détecté l'erreur.

Vous écrivez donc des tests pour votre code actuel et créez le code pour qu'il réussisse le test.Des mois plus tard, vous ou quelqu'un d'autre devez modifier la fonction dans votre code principal, car auparavant vous aviez déjà écrit du code de test pour cette fonction que vous exécutez à nouveau et le test peut échouer parce que le codeur a introduit une erreur logique dans la fonction ou renvoie complètement quelque chose. différent de ce que cette fonction est censée renvoyer.Encore une fois, sans le test en place, cette erreur pourrait être difficile à détecter car elle peut également affecter d'autres codes et passera inaperçue.

De plus, le fait que vous disposiez d'un programme informatique qui exécute votre code et le teste au lieu de le faire manuellement dans le navigateur page par page vous fait gagner du temps (tests unitaires pour javascript).Disons que vous modifiez une fonction utilisée par un script sur une page Web et qu'elle fonctionne très bien pour son nouvel objectif.Mais disons également, à titre d'arguments, qu'il existe une autre fonction que vous avez ailleurs dans votre code et qui dépend de cette fonction nouvellement modifiée pour qu'elle fonctionne correctement.Cette fonction dépendante peut maintenant cesser de fonctionner en raison des modifications que vous avez apportées à la première fonction. Cependant, sans tests exécutés automatiquement par votre ordinateur, vous ne remarquerez pas qu'il y a un problème avec cette fonction jusqu'à ce qu'elle soit réellement exécutée et vous devrez naviguer manuellement vers une page Web qui inclut le script qui exécute la fonction dépendante, alors seulement vous remarquerez qu'il y a un bug en raison de la modification que vous avez apportée à la première fonction.

Pour réitérer, l'exécution de tests lors du développement de votre application permettra de détecter ce type de problèmes lors du codage.N'ayant pas les tests en place, vous devrez parcourir manuellement l'ensemble de votre application et même dans ce cas, il peut être difficile de repérer le bogue, vous l'envoyez naïvement en production et après un certain temps, un utilisateur aimable vous envoie un rapport de bogue (qui ne sera pas aussi bon que vos messages d'erreur dans un cadre de test).

C'est assez déroutant lorsque vous entendez parler du sujet pour la première fois et que vous vous demandez : est-ce que je ne teste pas déjà mon code ?Et le code que vous avez écrit fonctionne déjà comme il est censé le faire, "pourquoi ai-je besoin d'un autre framework ?"...Oui, vous testez déjà votre code, mais un ordinateur est meilleur pour le faire.Il vous suffit d'écrire des tests suffisamment bons pour une fonction/unité de code une fois et le reste est pris en charge pour vous par le puissant processeur au lieu de devoir vérifier manuellement que tout votre code fonctionne toujours lorsque vous apportez une modification à votre code.

De plus, vous n'êtes pas obligé de tester unitairement votre code si vous ne le souhaitez pas, mais cela s'avère payant à mesure que votre projet/base de code commence à s'agrandir à mesure que les chances d'introduire des bogues augmentent.

Les tests unitaires et TDD en général vous permettent d'avoir des cycles de retour d'information plus courts sur le logiciel que vous écrivez.Au lieu d’avoir une grande phase de test à la toute fin de l’implémentation, vous testez progressivement tout ce que vous écrivez.Cela augmente considérablement la qualité du code, comme vous le voyez immédiatement, là où vous pourriez avoir des bugs.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow