Qu'est-ce que les tests unitaires?

voix
193

J'ai vu beaucoup de questions demandant « comment » de test unitaire dans une langue spécifique, mais pas question de demander « quoi », « pourquoi », et « quand ».

  • Qu'Est-ce que c'est?
  • Que fait-il pour moi?
  • Pourquoi devrais-je utiliser?
  • Quand dois-je utiliser (même si pas)?
  • Quels sont les pièges et les conceptions erronées
Créé 04/08/2008 à 17:27
source utilisateur
Dans d'autres langues...                            


20 réponses

voix
182

Les tests unitaires sont, grosso modo, tester des morceaux de votre code en vase clos avec le code de test. Les avantages immédiats qui viennent à l'esprit sont:

  • L'exécution des tests devient automatiser-mesure et reproductible
  • Vous pouvez tester à un niveau beaucoup plus granulaire que pointer-cliquer sur le test via une interface graphique

Notez que si votre code de test écrit dans un fichier, ouvre une connexion de base de données ou fait quelque chose sur le réseau, il est classé de façon plus appropriée 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. code de test unitaire doit être court, doux et rapide à exécuter.

Une autre façon de regarder les tests unitaires est que vous écrivez d'abord les tests. Ceci est connu comme le développement piloté par les tests (TDD pour faire court). TDD apporte des avantages supplémentaires:

  • Vous n'écrivez pas spéculative « je pourrais avoir besoin à l'avenir » code - juste assez pour faire les tests passent
  • Le code que vous avez écrit est toujours couvert par des tests
  • En écrivant le test d'abord, vous êtes obligé à réfléchir sur 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 les tests unitaires maintenant, je vous recommande de commencer là-dessus. Obtenez un bon livre, pratiquement tout livre xUnit fera parce que les concepts sont très transférables entre elles.

Parfois, l'écriture des tests unitaires peuvent être douloureuses. Quand il obtient de cette façon, essayer de trouver quelqu'un pour vous aider, et résister à la tentation de « il suffit d'écrire le code putain ». Les tests unitaires est un peu comme laver la vaisselle. Ce n'est pas toujours agréable, mais il garde votre cuisine métaphorique propre, et que vous voulez vraiment qu'il soit propre. :)


Edit: Une idée fausse vient à l'esprit, bien que je ne sais pas s'il est si commun. J'ai entendu un chef de projet dire que les tests unitaires ont fait l'équipe écrire tout le code deux fois. Si elle ressemble et se sent de cette façon, eh bien, vous le faites mal. Non seulement l'écriture des tests accélèrent habituellement le développement, mais il vous donne également un indicateur pratique « maintenant je suis fait » que vous n'auriez pas autrement.

Créé 04/08/2008 à 17:36
source utilisateur

voix
65

Je ne suis pas en désaccord avec Dan (bien qu'un meilleur choix peut-être de ne pas répondre) ... mais ...

Les tests unitaires est le processus de l'écriture de code pour tester le comportement et la fonctionnalité de votre système.

De toute évidence teste améliorer la qualité de votre code, mais c'est juste un avantage superficiel des tests unitaires. Les avantages réels sont:

  1. Facilitez de changer la mise en œuvre technique tout en vous assurant de ne pas modifier le comportement (refactoring). Correctement le code testé unitaire peut être agressive refactorisé / nettoyé avec peu de chance de casser quoi que ce soit sans le remarquer.
  2. Donner aux développeurs la confiance lors de l'ajout de comportement ou faire des corrections.
  3. Documenter votre code
  4. Indiquez les zones de votre code qui sont étroitement couplés. Il est difficile de code test unitaire qui est étroitement couplé
  5. Fournir un moyen d'utiliser votre API et rechercher des difficultés tôt
  6. Indique les méthodes et les classes qui ne sont pas très cohérent

Vous devez tester l'unité parce que son dans votre intérêt de livrer un produit maintenable et de qualité à votre client.

Je vous suggère de l'utiliser pour tout système ou d'une partie d'un système, quels modèles le comportement dans le monde réel. En d'autres termes, il est particulièrement bien adapté au développement des entreprises. Je ne l'utiliser pour les programmes à jeter / utilité. Je ne l'utiliser pour les pièces d'un système qui posent des problèmes à tester (UI est un exemple courant, mais ce n'est pas toujours le cas)

Le plus grand écueil est que les développeurs testent une trop grande unité, ou qu'ils considèrent comme une méthode d' une unité. Cela est particulièrement vrai si vous ne comprenez pas l' inversion de contrôle - dans ce cas , vos tests unitaires toujours se transformer en tests d'intégration de bout en bout. Test unitaire doit tester les comportements individuels - et la plupart des méthodes ont beaucoup de comportements.

La plus grande idée fausse est que les programmeurs ne devraient pas tester. Seuls les programmeurs mauvais ou paresseux croient que. le gars construction de votre toit ne doit pas tester? le médecin remplacement d'une valve cardiaque ne doit pas tester la nouvelle valve? Seul un programmeur peut vérifier que son code fait ce qu'il voulait à faire (QA peut tester des cas de pointe - comment le code se comporte quand il est dit de faire des choses que le programmeur n'a pas l'intention, et le client peut faire l'essai de réception - ce que le code ne ce que le client a payé pour cela à faire)

Créé 04/08/2008 à 17:41
source utilisateur

voix
40

La principale différence des tests unitaires, par opposition à « juste d' ouvrir un nouveau projet et tester ce code spécifique » est qu'il est automatisé , donc reproductible .

Si vous testez votre code manuellement, il peut vous convaincre que le code fonctionne parfaitement - dans son état actuel . Mais qu'en est- une semaine plus tard, quand vous avez fait une légère modification en elle? Êtes - vous prêt à tester à nouveau à nouveau à la main chaque fois que quelque chose change dans votre code? Très 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 seront vous montrer immédiatement chaque fois que quelque chose est cassé. Et si vous intégrons également les tests unitaires dans votre processus de construction automatisé, ils vous aviseront des bugs , même dans les cas où un changement apparemment complètement étranger a brisé quelque chose dans une partie éloignée de la base de code - quand il se produirait même pas vous qu'il ya un besoin de tester à nouveau cette fonctionnalité particulière.

Ceci est le principal avantage des tests unitaires sur les tests de la main. Mais attendez, il y a plus:

  • tests unitaires raccourcissent la boucle de rétroaction de développement de façon spectaculaire: avec un service d'essai séparé , il peut prendre des semaines pour que vous sachiez qu'il ya un bug dans votre code, date à laquelle vous avez déjà oublié une grande partie du contexte, donc vous pouvez prendre des heures à trouver et corriger le bug; OTOH avec les tests unitaires, le cycle de rétroaction est mesuré en secondes, et le processus de correction de bug est généralement le long des lignes d'un « oh sh * t, j'ai oublié de vérifier cette condition ici » :-)
  • tests unitaires efficacement documentent (votre compréhension) le comportement de votre code
  • forces de tests unitaires vous de réévaluer vos choix de conception, ce qui entraîne plus simple, plus propre conception

frameworks de tests unitaires, à son tour, il est facile pour vous d'écrire et d'exécuter vos tests.

Créé 14/03/2010 à 18:20
source utilisateur

voix
29

On ne m'a jamais enseigné les tests unitaires à l'université, et il m'a fallu un certain temps pour « obtenir » il. Je l'ai lu, je suis allé « ah, à droite, les tests automatisés, qui pourrait être cool je suppose », puis je l'avais oublié.

Il a fallu un peu plus longtemps avant de vraiment compris ce point: Disons que vous travaillez sur un grand système et vous écrire un petit module. Il compile, vous le mettez à l'épreuve, il fonctionne très bien, vous passez à la tâche suivante. Neuf mois sur la ligne et deux versions plus tard , quelqu'un d' autre fait un changement dans une certaine apparence partie sans rapport du programme, et il se casse le module. Pire encore, ils testent leurs changements et leur code fonctionne, mais ils ne testent pas votre module; l' enfer, ils ne savent même pas votre module existe .

Et maintenant, vous avez un problème: le code est cassé dans le coffre et personne ne sait même. Le meilleur des cas est un testeur interne trouve avant navire, mais le code de fixation que tard dans le jeu est cher. Et si aucun appareil de contrôle interne trouve ... eh bien, qui peut obtenir en effet très cher.

La solution est des tests unitaires. Ils attrapent des problèmes lorsque vous écrivez du code - ce qui est bien - mais vous auriez pu faire que la main. Le gain réel est qu'ils vont attraper des problèmes neuf mois à la ligne lorsque vous travaillez maintenant sur un projet complètement différent, mais un stagiaire d'été pense que ça va regarder si ces paramètres tidier étaient dans l' ordre alphabétique - puis le test unitaire vous avez écrit le chemin du retour tombe en panne, et quelqu'un lance des objets au stagiaire jusqu'à ce qu'il change de nouveau l'ordre des paramètres. C'est le « pourquoi » des tests unitaires. :-)

Créé 19/09/2008 à 13:45
source utilisateur

voix
12

Écaillage dans les avantages philosophiques des tests unitaires et TDD voici quelques-unes des principales observations qu'ils « lightbulb » qui m'a frappé sur mes premiers pas sur la voie de l'illumination TDD (pas nécessairement d'origine ou nouvelles) ...

  1. TDD ne signifie pas écrire deux fois la quantité de code. Code d'essai est généralement assez rapide et indolore pour écrire et est un élément clé de votre processus de conception et de façon critique.

  2. TDD vous aide à réaliser quand arrêter le codage! Vos tests que vous que vous donnent confiance en avez assez fait pour l'instant et peut cesser de peaufinage et de passer à autre chose.

  3. Les tests et le travail de code ensemble pour améliorer le code. Votre code pourrait être mauvais / buggy. Votre test pourrait être mauvais / buggy. Dans TDD vous misez sur les chances des deux être mauvais / poussette étant assez faible. Souvent, son test qui doit fixer, mais qui est toujours un bon résultat.

  4. TDD aide à la constipation de codage. Vous savez que le sentiment que vous avez tant de choses à faire, vous savez à peine où commencer? Il est vendredi après-midi, si vous venez de remettre à plus tard pour quelques heures de plus ... TDD vous permet d'étoffer très rapidement ce que vous pensez que vous devez faire, et obtient votre codage se déplaçant rapidement. En outre, comme des rats de laboratoire, je pense que nous répondons tous à ce grand feu vert et travailler plus dur pour voir à nouveau!

  5. Dans la même veine, ces types de créateurs peuvent voir ce qu'ils travaillent. Ils peuvent se promener au large pour un jus / cigarette / pause iphone et revenir à 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 sommes arrivés à la vie quand intervient ...

  6. Je pense qu'il était Fowler qui a dit: « Les tests imparfaites, souvent, sont dirigés beaucoup mieux que les tests parfaits qui ne sont jamais écrites du tout ». J'interpréte cela comme me donner l'autorisation d'écrire des tests où je pense qu'ils vont même être plus utile si le reste de ma couverture de code est lamentablement incomplète.

  7. TDD aide à toutes sortes de façon surprenante 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 à l'autre et vous donner un sentiment de supériorité injustifiée sur vos collègues non-test :)

Cette présentation est une excellente introduction à tous les tests de qu'implique la bonté délicieux.

Créé 24/08/2008 à 22:58
source utilisateur

voix
7

Je voudrais recommander le test xUnit livre Patterns par Gerard Meszaros. Il est grand , mais est une excellente ressource sur les tests unitaires. Voici un lien vers son site Web où il décrit les bases de tests unitaires. http://xunitpatterns.com/XUnitBasics.html

Créé 14/03/2010 à 19:10
source utilisateur

voix
5

J'utilise des tests unitaires pour gagner du temps.

Lorsque la logique métier (ou l'accès aux données) fonctionnalité de test peut souvent impliquer taper des choses dans un grand nombre d'écrans qui peuvent ou peuvent ne pas être encore terminé. Automatisant ces tests fait gagner du temps.

Pour moi, les tests unitaires sont une sorte de harnais de test modularisé. Il y a habituellement au moins un test par fonction publique. Je vous écris des tests supplémentaires pour couvrir les divers comportements.

Tous les cas particuliers que vous avez pensé de l'élaboration du code peut être enregistré dans le code dans les tests unitaires. Les tests unitaires deviennent aussi 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 casse code quelque chose dans mes tests unitaires puis de vérifier le code et avoir un développeur front-end trouver un problème.

Pour les tests d'accès aux données que je tente d'écrire des tests qui ont soit aucun changement ou nettoyer après eux-mêmes.

Les tests unitaires ne vont pas être en mesure de résoudre toutes les exigences de test. Ils seront en mesure de gagner du temps de développement et les pièces de base de test de l'application.

Créé 17/09/2008 à 01:38
source utilisateur

voix
5

Ceci est mon avis sur la question. Je dirais que les tests unitaires est la pratique de l' écriture des tests de logiciels pour vérifier que votre vrai logiciel fait ce qu'il est censé. Cela a commencé avec jUnit dans le monde Java et est devenu une meilleure pratique en PHP et avec SimpleTest et PHPUnit . Il 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 faire grand refactoring, la correction de bugs ou ajouter des fonctionnalités rapidement avec beaucoup moins peur 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 définit l'environnement de votre code, puis l'exerce; vous écrivez des affirmations, préciser la sortie prévu que vous devriez recevoir et exécuter votre script de test en utilisant un cadre tel que ceux mentionnés ci-dessus.

Le cadre se déroulera tous les tests contre votre code, puis faire rapport succès ou l'échec de chaque test. PHPUnit est exécuté à partir de la ligne de commande Linux par défaut, mais il existe des interfaces HTTP disponibles pour cela. SimpleTest est basé sur le Web par nature et est beaucoup plus facile de se lever et courir, l'OMI. En combinaison avec xDebug, PHPUnit peut vous donner des statistiques automatisées pour la couverture de code que certaines personnes trouvent très utiles.

Certaines équipes écrivent crochets de leur dépôt subversion afin que les tests unitaires sont exécutés automatiquement chaque fois que vous livrez des changements.

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

Créé 05/08/2008 à 00:53
source utilisateur

voix
4

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

Vous pouvez lire Introduction à Test Driven Development (TDD) ou un livre de Kent Beck Test Driven le développement: par exemple .

Ensuite, si vous voulez être sûr que vos tests couvrent une partie de votre code « bonne », vous pouvez utiliser un logiciel comme NCover , JCover , PartCover ou autre. Ils vous diront que le pourcentage de couverture de votre code. Selon combien vous êtes habile à TDD, vous saurez si vous avez pratiqué assez bien :)

Créé 14/03/2010 à 18:22
source utilisateur

voix
3

Je pense que le point que vous ne comprenez pas que les cadres de tests unitaires comme NUnit (et autres) vous aideront à automatiser les petits à des tests de taille moyenne. Habituellement , vous pouvez exécuter les tests dans une interface graphique (qui est le cas avec NUnit , par exemple) en cliquant simplement sur un bouton, puis - je l' espère - voir la barre de progression reste vert. Si elle devient rouge, le cadre montre quel test a échoué et exactement ce qui a mal tourné. Lors d' un test unitaire normal, vous utilisez souvent des affirmations, par exemple Assert.AreEqual(expectedValue, actualValue, "some description")- si les deux valeurs sont inégales , vous verrez une erreur « une description: attendu <expectedValue> mais était <actualValue> ».

Donc, en tant que test de l'unité de conclusion fera tester plus rapidement et beaucoup plus confortable pour les développeurs. Vous pouvez exécuter tous les tests unitaires avant d'engager un nouveau code afin que vous ne cassez pas le processus de construction d'autres développeurs sur le même projet.

Créé 14/03/2010 à 18:25
source utilisateur

voix
3

Les tests unitaires sont une pratique pour vous assurer que la fonction ou le module que vous allez mettre en œuvre va se comporter comme prévu (exigences) et aussi pour se assurer comment il se comporte dans des scénarios comme des conditions aux limites, et l'entrée non valide.

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

Créé 14/03/2010 à 18:22
source utilisateur

voix
3

Les tests unitaires sur le code écrit qui teste votre code d'application.

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

xUnit est là pour aider à ce test - ils sont des cadres qui aident à ce sujet. coureurs de test Une partie de c'est automatisé qui vous indiquent ce test n'a pas et qui passent les.

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

Vous pouvez avoir un test pour vérifier que l'exception attendue a été jeté, sans avoir à écrire vous bloquer toute la prise d'essai.

Créé 14/03/2010 à 18:19
source utilisateur

voix
3

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

Créé 17/09/2008 à 01:48
source utilisateur

voix
2

tous, que ce soit d'abord parler de tests unitaires ou d'autres types de tests automatisés (intégration, charge, test de l'interface utilisateur de etc.), la principale différence de ce que vous proposez est qu'il est automatisé, reproductible et il ne nécessite pas de ressources humaines à consommer (= personne doit effectuer les tests, ils courent généralement à une pression d'un bouton).

Créé 14/03/2010 à 18:22
source utilisateur

voix
2

Test Driven Development a en quelque sorte repris le terme test unitaire. En tant que oldtimer je mentionnerai la définition plus générique de celui-ci.

Unité de test signifie également tester un seul composant dans un système plus large. Ce composant pourrait être une dll, exe, bibliothèque de classes, etc. Il pourrait même être un seul système dans une application multi-système. En fin de compte l'unité de test finit par être le test de ce que vous voulez appeler une seule pièce d'un système plus vaste.

Vous pouvez ensuite passer à des tests intégrés ou d'un système en testant la façon dont tous les composants fonctionnent ensemble.

Créé 24/08/2008 à 23:34
source utilisateur

voix
2

-Tests unitaires est le test d'une unité de code (par exemple, une seule fonction) sans qu'il soit nécessaire de l'infrastructure que cette unité de code repose sur. dire à l'essai dans l'isolement.

Si, par exemple, la fonction que vous testez se connecte à une base de données et fait une mise à jour, dans un test unitaire, vous voudrez peut-être pas faire cette mise à jour. Vous si elle était un test d'intégration, mais dans ce cas, ce n'est pas.

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

Supposons que votre fonction récupéré quelques chiffres à partir d'une base de données et effectue ensuite un calcul de l'écart-type. Qu'est-ce que vous essayez de tester ici? Que l'écart type est calculé correctement ou que les données sont renvoyées à partir de la base de données?

Lors d'un test de l'unité que vous voulez juste pour vérifier que l'écart-type est calculé correctement. Dans un test d'intégration que vous souhaitez tester le calcul de l'écart-type et la récupération de la base de données.

Créé 15/08/2008 à 18:42
source utilisateur

voix
1

Cela répond à la raison pour laquelle vous devriez faire des tests unitaires.


Les 3 vidéos ci-dessous les tests unitaires de couverture en javascript, mais les principes généraux applicables dans la plupart des langues.

Tests unitaires: Minutes maintenant Will Save heures plus tard - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc

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

Testable code JavaScript - https://www.youtube.com/watch?v=OzjogCFO4Zo


Maintenant, je suis en train d'apprendre sur le sujet, donc je ne peux pas être 100% correct et il y a plus à ce 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 maintenu séparé de votre code principal) qui appelle une fonction dans votre code principal avec entrée (arguments) que la fonction exige et le code vérifie ensuite si elle récupère une valeur de retour valide. Si elle ne se remettre une valeur valide le cadre de tests unitaires que vous utilisez pour exécuter les tests montre un feu vert (tout bon) si la valeur est invalide, vous obtenez un feu rouge et vous pouvez alors résoudre le problème tout de suite avant libérer le nouveau code à la production, sans test, vous pouvez effectivement ne pas avoir pris l'erreur.

Donc, vous écrivez des tests pour vous code actuel et de créer le code pour qu'il passe le test. Quelques mois plus tard vous ou quelqu'un d'autre besoin de modifier la fonction dans votre code principal, parce que plus tôt vous aviez déjà un code de test écrit pour cette fonction vous exécutez à nouveau et le test peut échouer parce que le codeur introduit une erreur de logique dans la fonction ou retourner quelque chose de complètement différent de ce que cette fonction est censée revenir. Encore une fois, sans le test en place cette erreur pourrait être difficile à traquer car il peut éventuellement affecter d'autres codes aussi bien et passer inaperçu.


De plus, le fait que vous avez un programme informatique qui passe par votre code et teste au lieu de vous, il fait manuellement dans la page du navigateur par la page fait gagner du temps (tests unitaires pour le javascript). Disons que vous modifiez une fonction qui est utilisée par un script sur une page Web et il fonctionne très bien pour sa nouvelle destination. Mais, disons aussi bien des arguments qu'il existe une autre fonction que vous avez quelque part ailleurs dans votre code qui dépend de cette fonction nouvellement modifiée pour qu'il puisse fonctionner correctement. Cette fonction dépendante peut maintenant cesser de fonctionner à cause des changements que vous avez apportées à la première fonction, mais sans essais en place qui sont exécutés automatiquement par votre ordinateur, vous ne remarquerez pas qu'il ya un problème avec cette fonction jusqu'à ce qu'il soit effectivement exécuté et vous devrez naviguer manuellement vers une page Web qui inclut le script qui exécute la fonction dépendante, alors seulement vous remarquez qu'il ya un bug à cause du changement que vous avez fait à la première fonction.

Je le répète, ayant des tests qui sont exécutés tout en développant votre application va attraper ce genre de problèmes que vous codez. Ne pas avoir les essais en place, vous auriez à effectuer manuellement l'application entière et même alors, il peut être difficile de repérer le bug, vous envoyez naïvement à la production et après un certain temps un utilisateur de type vous envoie un rapport de bogue (qui ne sera pas aussi bon que vos messages d'erreur dans un cadre de test).


Il est assez déroutant quand vous entendez du sujet et vous pensez à vous-même, suis-je pas déjà testé mon code? Et le code que vous avez écrit fonctionne comme il est censé déjà, « pourquoi ai-je besoin d'un autre cadre? » ... Oui, vous êtes déjà tester votre code, mais un ordinateur est mieux à le faire. Il vous suffit d'écrire des tests assez bon pour une fonction / unité de code une fois et le reste est pris en charge pour vous par le cpu puissant au lieu de vous avoir à vérifier manuellement que tous votre code fonctionne toujours lorsque vous modifiez votre code.

En outre, vous n'avez pas à l'unité tester votre code si vous ne voulez pas, mais elle est payante que votre projet / base de code commence à se développer plus que les risques d'introduction de bugs augmente.

Créé 18/07/2015 à 18:34
source utilisateur

voix
1

Que faites-vous si vous êtes donné un tas de merde et croire que vous êtes coincé dans un état perpétuel de nettoyage que vous savez avec l'ajout d'une nouvelle fonctionnalité ou un code peut briser le jeu actuel, car le logiciel actuel est comme une maison de cartes?

Comment pouvons-nous faire des tests unitaires alors?

Vous commencez petit. Le projet que je viens en avait pas des tests unitaires jusqu'à il y a quelques mois. Lorsque la couverture est que faible, nous simplement choisir un fichier qui n'a pas de couverture et cliquez sur « ajouter des tests ».

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

(La meilleure partie est que, même à ce faible niveau de couverture, nous avons déjà couru dans de nombreux cas, du code de faire la mauvaise chose, et le test a attrapé. C'est une énorme source de motivation pour pousser les gens à ajouter d'autres tests.)

Créé 22/08/2008 à 19:19
source utilisateur

voix
1

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

J'ai pris un coup de feu à TDD récemment quand je rédigeais une routine pour sauvegarder et restaurer les paramètres. Tout d'abord, je vérifiais que je pourrais créer l'objet de stockage. Alors, qu'il avait la méthode que je devais appeler. Alors, que je pouvais l'appeler. Alors, que je pouvais passer des paramètres. Alors, que je pouvais passer des paramètres spécifiques. Et ainsi de suite, jusqu'à ce que je vérifiais enfin qu'il sauverait le paramètre spécifié, permettez-moi de le changer, et puis la restaurer, pour plusieurs syntaxes différentes.

Je n'ai pas à la fin, parce que je avais besoin-la-routine maintenant bon sang, mais ce fut un bon exercice.

Créé 22/08/2008 à 19:10
source utilisateur

voix
0

-Tests unitaires et TDD en général vous permet d'avoir des cycles plus courts de rétroaction sur le logiciel que vous écrivez. Au lieu d'avoir une grande phase de test à la fin de la mise en œuvre, tester progressivement tout ce que vous écrivez. Cette qualité du code augmente beaucoup, comme vous voyez immédiatement, où vous pourriez avoir des bugs.

Créé 03/05/2017 à 09:33
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more