glossary - Qu'est-ce qu'un test unitaire?

Translate

J'ai vu de nombreuses questions demandant «comment» faire 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 (même si non)?
  • Quels sont les pièges et les idées fausses courants
This question and all comments follow the "Attribution Required."

Toutes les réponses

Translate

Les tests unitaires consistent, en gros, à tester des bits de votre code de manière isolée avec du code de test. Les avantages immédiats qui me viennent à l'esprit sont:

  • L'exécution des tests devient automatisable et répétable
  • 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 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, simple et rapide à exécuter.

Une autre façon de regarder les tests unitaires consiste à écrire les tests en premier. Ceci est connu sous le nom de Test-Driven Development (TDD pour faire court). TDD apporte des avantages supplémentaires:

  • Vous n'écrivez pas de code spéculatif "J'aurai besoin de ceci 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 test unitaire 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, l'écriture de tests unitaires peut être pénible. Quand cela arrive, essayez de trouver quelqu'un pour vous aider et résistez à la tentation de "juste écrire le putain de code". Les tests unitaires sont 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. :)


Edit: 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 ont amené 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 cela vous donne également un indicateur pratique "maintenant j'ai terminé" que vous n'auriez pas autrement.

La source
Translate

Je ne suis pas en désaccord avec Dan (bien qu'un meilleur choix soit 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 avantages réels 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é par unité peut être réusiné / nettoyé de manière agressive avec peu de chances de casser quoi que ce soit sans le remarquer.
  2. Donnez confiance aux développeurs lors de l'ajout de comportements ou de la résolution de problèmes.
  3. Documentez votre code
  4. Indiquez les zones de votre code qui sont étroitement liées. Il est difficile de tester un code qui est étroitement couplé
  5. Fournissez un moyen d'utiliser votre API et recherchez 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 un test unitaire 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 d'entreprise. Je ne l'utiliserais pas pour des 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 piège 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 pasInversion 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 devrait-il pas tester la nouvelle valve? Seul un programmeur peut tester que son code fait ce qu'il avait l'intention de faire (l'assurance qualité peut tester les cas de pointe - comment le code se comporte quand on lui dit de faire des choses que le programmeur n'a pas prévues, et le client peut faire un test d'acceptation - le code fait-il ce que le client a payé pour cela)

La source
Translate

La principale différence entre les tests unitaires et "simplement ouvrir un nouveau projet et tester ce code spécifique" est que c'estautomatique, Doncré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 à recommencer à la main à chaque foisn'importe quoides changements dans votre code? Très probablement pas :-(

Mais si tu peuxexécutez vos tests à tout moment, d'un simple clic, exactement de la même manière, en quelques secondes, puis ilsvolonté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 complètement 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 unitairesraccourcir la boucle de rétroaction de développementdramatiquement: avec un service de test séparé, cela peut prendre des semaines avant que vous sachiez qu'il y a un bogue dans votre code, auquel temps 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 bogue est généralement le long des lignes d'un "oh sh * t, j'ai oublié de vérifier cette condition ici" :-)
  • tests unitaires efficacementdocument(votre compréhension de) le comportement de votre code
  • les tests unitaires vous obligent à réévaluer vos choix de conception, ce quiconception plus simple et plus propre

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

La source
Translate

Je n'ai jamais appris les tests unitaires à l'université, et il m'a fallu un certain temps pour «l'obtenir». J'ai lu à ce sujet, je suis allé "ah, d'accord, des tests automatisés, ça pourrait être cool je suppose", et 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 certainsapparemmentpartie non liée du programme, et il brise 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 moduleexiste.

Et maintenant, vous avez un problème: du code cassé est dans le coffre et personne ne le sait. Le meilleur cas est qu'un testeur interne le trouve avant l'expédition, mais réparer un code qui tard dans le jeu coûte cher. Et si aucun testeur interne ne le trouve ... eh bien, cela peut coûter 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 attraperont des 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 ce sera plus net si ces paramètres étaient classés par ordre alphabétique - puis le test unitaire vous avez écrit en arrière échoue, et quelqu'un jette des choses au stagiaire jusqu'à ce qu'il modifie l'ordre des paramètres.C'estle «pourquoi» des tests unitaires. :-)

La source
Translate

En jetant un coup d'œil aux pros philosophiques des tests unitaires et du TDD, voici quelques-unes de leurs observations clés "ampoules" qui m'ont frappé lors de mes premiers pas provisoires sur la route de l'illumination du TDD (pas d'original ni nécessairement d'actualité) ...

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

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

  3. Les tests et le code fonctionnent ensemble pour obtenir un meilleur code. Votre code peut être incorrect / bogué. Votre TEST peut être défectueux / bogué. Dans TDD, vous misez sur les chances que LES DEUX soient mauvais / buggy étant 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 connaissez ce sentiment que vous avez tant à faire, vous savez à peine par où commencer? C'est vendredi après-midi, si vous tergiversez pendant quelques heures de plus ... 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épondons tous à ce grand feu vert et travaillons plus dur pour le revoir!

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

  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 du code d'un projet à un autre et vous donner un sentiment injustifié de supériorité sur vos collègues non testeurs :)

Cette présentationest une excellente introduction à tous les délicieux tests de qualité.

La source
Translate

Je voudrais recommander le livre xUnit Testing Patterns de Gerard Meszaros. C'est volumineux mais c'est 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

La source
Translate

J'utilise des tests unitaires pour gagner du temps.

Lors de la création de fonctionnalités de test de logique métier (ou d'accès aux données), il est souvent nécessaire de saisir des éléments dans 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 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 du développement du code peuvent être enregistrés dans le code dans les 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 de vérifier 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 nettoient après eux-mêmes.

Les tests unitaires ne pourront pas résoudre toutes les exigences de test. Ils pourront gagner du temps de développement et tester les parties centrales de l'application.

La source
Translate

Ceci est mon point de vue. Je dirais que les tests unitaires sont la pratique d'écrire des tests logiciels pour vérifier que votre vrai logiciel fait ce qu'il est censé faire. Cela a commencé avecjUnitdans le monde Java et est devenue une bonne pratique en PHP avecSimpleTestetphpUnit. C'est une pratique de base 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 avez une couverture de test suffisante, vous pouvez effectuer une refactorisation majeure, corriger des bogues ou ajouter des fonctionnalités rapidement sans craindre beaucoup moins 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 met en place l'environnement de votre code et l'exerce ensuite; vous écrivez des assertions, spécifiez la sortie prévue que vous devez recevoir, puis exécutez votre script de test en utilisant un framework tel que ceux mentionnés ci-dessus.

Le framework exécutera tous les tests par rapport à votre code, puis signalera le succès ou 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 à démarrer, IMO. En combinaison avec xDebug, phpUnit peut vous donner 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 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.

La source
Translate

Bibliothèques commeNUnit, xUnitouJUnitsont juste obligatoires si vous souhaitez développer vos projets en utilisant leTDDapproche popularisée par Kent Beck:

Tu peux lireIntroduction au développement piloté par les tests (TDD)ou le livre de Kent BeckDé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 commeNCover, JCover, PartCoverou 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é :)

La source
Guy
Translate

Le test unitaire est le test d'une unité de code (par exemple, une fonction unique) sans avoir besoin de l'infrastructure sur laquelle cette unité de code repose. 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, vous ne souhaiterez peut-être pas effectuer cette mise à jour dans un test unitaire. 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 vérifier que l'écart type est calculé correctement. Dans un test d'intégration, vous souhaitez tester le calcul de l'écart type et l'extraction de la base de données.

La source
Translate

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

leUnité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 avec ces tests - ce sont des frameworks qui vous aident à cela. Une partie de cela est constituée de lanceurs de tests automatisés qui vous indiquent quel test a échoué et lequel réussit.

Ils ont également des installations pour configurer le code commun dont vous avez besoin dans chaque test avant la main et le démolir 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 vous-même le bloc try catch.

La source
Translate

Je pense que le point que vous ne comprenez pas, c'est que les frameworks de test unitaire comme NUnit (et autres) vous aideront àautomatisertests de petite à moyenne taille. Habituellement, vous pouvez exécuter les tests dans une interface graphique (c'est le cas avecNUnit, par exemple) en cliquant simplement sur un bouton, puis - espérons-le - voir la barre de progression rester verte. S'il devient rouge, le cadre 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 exempleAssert.AreEqual(expectedValue, actualValue, "some description")- donc si les deux valeurs sont inégales, vous verrez une erreur indiquant "une description: attendue <expectedValue> mais était <actualValue>".

Donc, en guise de 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 génération d'autres développeurs sur le même projet.

La source
Translate

UtilisationTémoignage. Tout ce que vous devez savoir est là :)

La source
Translate

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 s'assurer de son comportement dans des scénarios tels que des conditions aux limites et une entrée invalide.

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

La source
Translate

Test Driven Development a en quelque sorte repris le terme de test unitaire. En tant que vieux chronométreur, je mentionnerai la définition 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 pourrait être une DLL, un exe, une bibliothèque de classes, etc. Il pourrait même s'agir d'un seul système dans une application multi-système. Ainsi, le test unitaire finit par être le test de tout ce que vous voulez appeler une seule pièce d'un système plus grand.

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

La source
Translate

Tout d'abord, qu'il s'agisse de tests unitaires ou de tout autre type de test automatisé (intégration, charge, test de l'interface utilisateur, etc.), la principale différence par rapport à ce que vous suggérez est qu'il est automatisé, répétable et 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).

La source
Translate

Je suis allé à une présentation sur les tests unitaires à FoxForward 2007 et on m'a dit de ne jamais tester les unités qui fonctionnent 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 majeure partie du codage que je fais ces jours-ci. :-)

J'ai pris une photo chez TDD récemment 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, qu'il avait la méthode que j'avais besoin d'appeler. Alors, 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 enregistre le paramètre spécifié, me permet de le modifier, puis de le restaurer, pour plusieurs syntaxes différentes.

Je ne suis pas arrivé à la fin, car j'avais besoin de la routine maintenant, mais c'était un bon exercice.

La source
Translate

Que faites-vous si vous recevez 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 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'a fait l'objet d'aucun test unitaire jusqu'à il y a quelques mois. Lorsque la couverture était aussi faible, nous choisissions simplement un fichier sans couverture et cliquez sur «ajouter des tests».

À l'heure actuelle, nous en sommes à plus de 40% et nous avons réussi à ramasser la plupart des fruits à portée de main.

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

La source
Translate

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 à la plupart des langues.

Test unitaire: quelques minutes économisent des heures plus tardhttps://www.youtube.com/watch?v=_UmmaPe8Bzc

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

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


Maintenant, j'apprends juste le sujet, donc je ne suis peut-être pas correct à 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 un code de test (qui est séparé de votre code principal) qui appelle une fonction dans votre code principal avec l'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 test unitaire 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 vous relâchez 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 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 car le codeur a introduit une erreur logique dans la fonction ou renvoyer quelque chose complètement différent de ce que cette fonction est censée renvoyer. Encore une fois, sans le test en place, cette erreur peut être difficile à détecter car elle peut également affecter d'autres codes et passera inaperçue.


De plus, le fait que vous ayez un programme informatique qui exécute votre code et le teste au lieu de le faire manuellement dans le navigateur page par page fait gagner du temps (test unitaire pour javascript). Disons que vous modifiez une fonction qui est utilisée par un script sur une page Web et que cela fonctionne très bien pour son nouvel objectif. Mais, disons aussi pour les arguments 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 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 bogue en raison de la modification que vous avez apportée à la première fonction.

Pour réitérer, avoir des tests qui sont exécutés lors du développement de votre application détectera ce type de problèmes pendant que vous codez. N'ayant pas les tests en place, vous devrez parcourir manuellement toute votre application et même dans ce cas, il peut être difficile de repérer le bogue, naïvement vous l'envoyez 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 dites, est-ce que je ne teste pas déjà mon code? Et le code que vous avez écrit fonctionne comme il est censé le faire déjà, "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 une fois suffisamment de bons tests pour une fonction / unité de code et le reste est pris en charge pour vous par le puissant processeur au lieu de vous obliger à vérifier manuellement que tout votre code fonctionne toujours lorsque vous modifiez votre code.

De plus, vous n'avez pas à tester votre code unitaire si vous ne le souhaitez pas, mais cela est payant car votre projet / base de code commence à augmenter à mesure que les chances d'introduire des bogues augmentent.

La source
aap
Translate

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 phase de test importante à 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 bogues.

La source