Qu'est-ce qu'un test unitaire? [fermé]

J'ai vu de nombreuses questions demandant «comment» effectuer un test unitaire 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 (également quand ce n'est pas le cas)?
• Quels sont les pièges courants et les idées fausses

Le test unitaire consiste, en gros, à tester des bits de votre code de manière isolée avec le code de test. Les avantages immédiats qui viennent à l'esprit sont:

• L'exécution des tests devient automatisable et répétable
• Vous pouvez tester à un niveau beaucoup plus granulaire que le test 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 fait quelque chose sur le réseau, il est mieux classé 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 de test unitaire doit être court, doux et rapide à exécuter.

Une autre façon de voir les tests unitaires est de commencer par écrire les tests. C'est ce qu'on appelle le développement piloté par les tests (TDD pour faire court). TDD apporte des avantages supplémentaires:

• Vous n'écrivez pas de code spéculatif "J'aurais peut-être besoin de cela 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 façon dont vous voulez 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 commencer. Obtenez 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 douloureux. Dans ce cas, essayez de trouver quelqu'un pour vous aider et résistez à la tentation de "simplement écrire le fichu code". Les tests unitaires sont un peu comme laver 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. :)

Edit: Une idée fausse me vient à l'esprit, même si je ne suis pas sûr que ce soit si courant. J'ai entendu un chef de projet dire que les tests unitaires ont obligé l'équipe à écrire tout le code deux fois. Si cela ressemble et se sent de cette façon, eh bien, vous le faites mal. 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.

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

Le test unitaire est 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:

1. Facilitez la modification de l'implémentation technique tout en vous assurant de ne pas modifier le comportement (refactoring). Un code correctement testé à l'unité peut être refactorisé / nettoyé de manière agressive avec peu de chance de casser quoi que ce soit sans le remarquer.
2. Donnez confiance aux développeurs lorsqu'ils ajoutent un comportement ou apportent des correctifs.
3. Documentez votre code
4. Indiquez les zones de votre code qui sont étroitement couplées. Il est difficile de tester un code unitaire étroitement couplé
5. Fournir un moyen d'utiliser votre API et rechercher les difficultés dès le début
6. Indique des méthodes et des classes qui ne sont pas très 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 n'importe quel système, ou partie d'un système, qui modélise le comportement du monde réel. En d'autres termes, il est particulièrement bien adapté au développement des entreprises. Je ne l'utiliserais pas pour les programmes jetables / utilitaires. Je ne l'utiliserais pas pour des parties d'un système qui sont problématiques à tester (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 qu'ils considèrent une méthode comme une unité. Cela est particulièrement vrai si vous ne comprenez pas l' inversion de contrôle - auquel cas vos tests unitaires se transformeront toujours en tests d'intégration de bout en bout. Le test unitaire devrait 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 gars qui construit votre toit ne devrait-il pas le tester? Le médecin qui remplace une valve cardiaque ne doit-il pas tester la nouvelle valve? Seul un programmeur peut tester que son code fait ce qu'il avait l'intention de faire. ce que le client a payé pour cela)

La principale différence des tests unitaires, par opposition à "simplement ouvrir un nouveau projet et tester ce code spécifique" est qu'il est automatisé , donc répétable .

Si vous testez votre code manuellement, il 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 que quelque chose change dans votre code? Probablement pas :-(

Mais si vous pouvez exécuter vos tests à tout moment, en un seul clic, exactement de la même façon, en quelques secondes , ils vont 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 sur les bogues même dans les cas où un changement apparemment complètement indépendant a cassé quelque chose dans une partie éloignée de la base de code - quand 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:

• les tests unitaires raccourcissent considérablement la boucle de rétroaction de développement : avec un département de test séparé, il peut prendre des semaines pour que vous sachiez qu'il y a un bogue dans votre code, moment où vous avez déjà oublié une grande partie du contexte, donc cela peut vous prendre des heures pour trouver et corriger le bogue; OTOH avec des tests unitaires, le cycle de rétroaction est mesuré en secondes, et le processus de correction de bugs est généralement le long d'un "oh sh * t, j'ai oublié de vérifier cette condition ici" :-)
• tests unitaires efficaces documentent (votre compréhension) le comportement de votre code
• les tests unitaires vous obligent à réévaluer vos choix de conception, ce qui se traduit par une conception plus simple et plus propre

Les cadres de tests unitaires, à leur tour, vous permettent d'écrire et d'exécuter facilement vos tests.

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

Il a fallu un peu plus de temps avant de vraiment comprendre le point: disons que vous travaillez sur un grand système et que vous écrivez un petit module. Il compile, vous le mettez à l'épreuve, cela fonctionne très bien, vous passez à la tâche suivante. Neuf mois plus tard et deux versions plus tard, quelqu'un d'autre modifie une partie apparemment indépendante du programme, et il casse le module. Pire, ils testent leurs modifications et leur code fonctionne, mais ils ne testent pas votre module; diable, ils ne savent peut-être même pas que votre module existe .

Et maintenant vous avez un problème: le code cassé est dans le coffre et personne ne le sait même. Le meilleur cas est qu'un testeur interne le trouve avant l'expédition, mais réparer le code tard dans le jeu coûte cher. Et si aucun testeur interne ne le trouve ... eh bien, cela peut devenir très cher.

La solution est les tests unitaires. Ils attraperont des problèmes lorsque vous écrivez du code - ce qui est bien - mais vous auriez pu le faire à la main. Le vrai avantage est qu'ils vont attraper des problèmes neuf mois plus tard lorsque vous travaillez maintenant sur un projet complètement différent, mais un stagiaire d'été pense que cela aurait l'air plus ordonné si ces paramètres étaient dans l'ordre alphabétique - puis le test unitaire vous avez écrit le chemin du retour échoue, et quelqu'un lance des choses au stagiaire jusqu'à ce qu'il change l'ordre des paramètres. C'est le "pourquoi" des tests unitaires. :-)

Voici quelques-unes des observations clés de "l'ampoule" qui m'ont frappé lors de mes premiers essais sur la voie de l'illumination TDD (pas d'original ou nécessairement de nouvelles) ...

1. TDD ne signifie PAS écrire deux fois la quantité de code. Le code de test est généralement assez rapide et indolore à écrire et est un élément clé de votre processus de conception et de manière critique.

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

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

4. TDD aide à coder la constipation. Vous savez ce sentiment que vous avez tant à faire que vous savez à peine par où commencer? C'est vendredi après-midi, si vous tergiversez quelques heures de plus ... TDD vous permet d'étoffer très rapidement ce que vous pensez que vous devez 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!

5. Dans la même veine, ces types de concepteurs peuvent VOIR ce sur quoi ils travaillent. Ils peuvent s'éloigner pour une pause jus / cigarette / iphone et retourner à un moniteur qui leur donne immédiatement une indication visuelle de 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 ...

6. Je pense que c'est Fowler qui a dit: "Les tests imparfaits, exécutés fréquemment, sont bien meilleurs que les tests parfaits qui ne sont jamais écrits du tout". J'interprète cela comme me donnant la permission d'écrire des tests où je pense qu'ils seront les plus utiles même si le reste de ma couverture de code est malheureusement incomplet.

7. TDD aide de toutes sortes de façons 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 tests de qualité délicieux implique.

Je voudrais recommander le livre xUnit Testing Patterns de Gerard Meszaros. Il est grand mais constitue une excellente ressource pour 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 de la logique métier (ou de l'accès aux données), la fonctionnalité de test peut souvent impliquer de taper des éléments dans de nombreux écrans qui peuvent ou non être terminés. L'automatisation de ces tests fait gagner du temps.

Pour moi, les tests unitaires sont une sorte de faisceau de test modulaire. Il y a 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 de l'élaboration 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 que de vérifier le code et qu'un développeur front-end trouve 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 seront pas en mesure de résoudre toutes les exigences de test. Ils pourront gagner du temps de développement et tester les parties centrales de l'application.

Voici ma façon de voir les choses. Je dirais que les tests unitaires consistent à é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 devenu une meilleure pratique en PHP avec SimpleTest et phpUnit . C'est une pratique fondamentale de la programmation extrême 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, une correction de bogues ou ajouter des fonctionnalités rapidement avec beaucoup moins de crainte d'introduire d'autres problèmes.

Il 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 la sortie prévue que vous devez recevoir, puis exécutez votre script de test à l'aide d'un cadre tel que ceux mentionnés ci-dessus.

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

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

Il est recommandé de conserver vos tests unitaires dans le même référentiel que votre application.

Des bibliothèques comme NUnit , xUnit ou JUnit sont simplement obligatoires si vous souhaitez développer vos projets en utilisant l' approche TDD popularisée par Kent Beck:

Vous pouvez lire Introduction to Test Driven Development (TDD) ou le livre de Kent Beck Test Driven Development: By Example .

Ensuite, si vous voulez être sûr que vos tests couvrent une "bonne" partie de votre code, vous pouvez utiliser des logiciels comme NCover , JCover , PartCover ou autre. Ils vous indiqueront le pourcentage de couverture de votre code. En fonction de vos compétences en TDD, vous saurez si vous l'avez assez bien pratiqué :)

Le test unitaire est le test d'une unité de code (par exemple une seule fonction) sans avoir besoin de l'infrastructure sur laquelle cette unité de code s'appuie. c'est-à-dire le tester 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 ait récupéré des nombres dans une base de données, puis effectué 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 de la base de données?

Dans un test unitaire, vous voulez 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.

Le test unitaire consiste à écrire du code qui teste le code de votre application.

La partie Unité 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 avec ces tests - ce sont des frameworks qui aident à cela. Les lanceurs de tests automatisés vous indiquent en partie quels tests échouent et lesquels réussissent.

Ils ont également des installations pour configurer le code commun dont vous avez besoin dans chaque test avant la main et le déchirer lorsque tous les tests sont terminés.

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

Je pense que le point que vous ne comprenez pas, c'est que les cadres de tests unitaires comme NUnit (et similaires) vous aideront à automatiser les 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 indique quel test a échoué et ce qui s'est exactement passé. Dans un test unitaire normal, vous utilisez souvent des assertions, par exempleAssert.AreEqual(expectedValue, actualValue, "some description") - donc si les deux valeurs sont inégales, vous verrez une erreur disant «une description: <expectedValue> attendue mais était <Valeuractuelle>».

Donc, 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 le nouveau code afin de ne pas interrompre le processus de génération d'autres développeurs sur le même projet.

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

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

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

Le développement piloté par les tests a en quelque sorte repris le terme test unitaire. En tant que vieux temporisateur, je mentionnerai sa définition plus générique.

Le test unitaire signifie également tester un seul composant dans un système plus grand. Ce composant unique pourrait ê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. Donc, finalement, le test unitaire finit par être le test de tout ce que vous voulez appeler une seule pièce d'un plus grand système.

Vous passeriez ensuite au test intégré ou au système en testant comment tous les composants fonctionnent ensemble.

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

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

J'ai pris une photo de TDD récemment alors que 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, qu'il avait la méthode que j'avais besoin d'appeler. Ensuite, que je pourrais l'appeler. Ensuite, que je pourrais lui passer des paramètres. Ensuite, que je pourrais lui passer 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 arrivé à la fin, parce que j'avais besoin de la routine maintenant, mais c'était un bon exercice.

Que faites-vous si on vous donne un tas de merde et que vous semblez être coincé dans un état de nettoyage perpétuel que vous savez avec l'ajout de toute nouvelle fonctionnalité ou code peut casser l'ensemble actuel parce que 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 venais de commencer n'avait aucun test unitaire jusqu'à il y a quelques mois. Lorsque la couverture était aussi faible, nous sélectionnions simplement un fichier sans couverture et cliquions sur "Ajouter des tests".

En ce moment, nous sommes à plus de 40%, et nous avons réussi à cueillir la plupart des fruits bas.

(La meilleure partie est que même à ce faible niveau de couverture, nous avons déjà rencontré de nombreux cas de code faisant la mauvaise chose, et les tests l'ont détecté. C'est une énorme motivation pour pousser les gens à ajouter plus de tests.)

Cela explique pourquoi vous devriez faire des tests unitaires.

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

Test unitaire: les minutes économiseront maintenant des heures plus tard - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

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

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

Maintenant, j'apprends juste sur le sujet, donc je ne suis peut-être pas 100% correct 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 une entrée (arguments) requise par la fonction et le code vérifie ensuite s'il récupère une valeur de retour valide. S'il récupère une valeur valide, le cadre de tests unitaires que vous utilisez pour exécuter les tests affiche un feu vert (tout est bon) si la valeur n'est pas valide, vous obtenez un feu rouge et vous pouvez ensuite résoudre le problème immédiatement avant publier le nouveau code en production, sans tester, vous n'avez peut-être pas détecté l'erreur.

Vous écrivez donc des tests pour votre code actuel et créez le code pour qu'il passe 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 le code de test pour cette fonction, vous l'exécutez à nouveau et le test peut échouer car le codeur a introduit une erreur logique dans la fonction ou renvoyé quelque chose complètement différent de ce que cette fonction est censée retourner. Encore une fois sans le test en place, cette erreur pourrait être difficile à localiser car elle peut également affecter d'autres codes et passer inaperçue.

Le fait que vous ayez un programme informatique qui parcourt votre code et le teste au lieu de le faire manuellement dans le navigateur page par page permet également de gagner du temps (tests unitaires pour javascript). Disons que vous modifiez une fonction qui est utilisée par un script sur une page Web et qu'elle fonctionne très bien pour son nouvel objectif. Mais, disons aussi pour des raisons d'argument qu'il y a une autre fonction que vous avez ailleurs dans votre code 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, mais sans tests en place qui sont 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 tu'

Pour réitérer, le fait d'avoir des tests exécutés lors du développement de votre application détectera ce type de problèmes lors du codage. Sans avoir les tests en place, vous devrez parcourir manuellement toute votre application et même alors, 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 framework de test).

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

En outre, vous n'avez pas à tester votre code à l'unité si vous ne le souhaitez pas, mais cela est payant car votre base de projet / 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 rétroaction 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, où vous pourriez avoir des bogues.