Comment démarrer les tests unitaires ou TDD?

Question

J'ai lu beaucoup de messages qui m'ont convaincu que je devrais commencer à écrire le test d'unité, j'ai également commencé à utiliser l'injection de dépendance (Unity) pour faciliter la moquerie, mais je ne sais toujours pas à quel stade je devrais commencer à écrire l'unité tests et simulations, et comment ou par où commencer.

La méthode préférée consisterait-elle à rédiger les tests unitaires avant les méthodes décrites dans la méthodologie TDD?

Existe-t-il une méthodologie ou une méthode différente pour les tests unitaires?

Answer 1

Tout d'abord un Test / test après:

Il convient de noter que le test "d'abord" dans le cadre de la DRT est tout autant (si pas plus) à voir avec la conception qu'il est à faire avec des tests unitaires. C'est un logiciel de développement technique dans son propre droit-écrit les résultats des tests dans un souci constant de perfectionnement de la conception.

Sur une autre note: Si il y a un avantage significatif à l'ATS à partir d'un pur tests unitaires point de vue, c'est qu'il est beaucoup plus difficile (mais pas impossible) d'écrire un test qui est mal quand faire TDD. Si vous écrivez le tester à l'avance, il doit toujours échouer parce que la logique requise pour rendre le test n'existe pas encore. Si vous écrivez le test par la suite, la logique devrait être là, mais si le test est buggé ou de tester quelque chose de mal, il peut passer indépendamment.

I. e. si vous écrivez un mauvais test, vous pouvez obtenir une lumière verte lorsque vous vous attendez à un rouge (si vous connaissez le test est mauvais). Si vous écrivez un mauvais test par la suite, vous obtiendrez une lumière verte lorsque vous prévu un vert (pas au courant de la mauvaise test).

Livres

La pragmatique de tests unitaires livre vaut bien un coup d'oeil, comme le Roy Osherove de "l'Art de L'Unité de Test". La pragmatique livre est plus ciblées sur les différents types de test des entrées vous pouvez essayer de trouver des bugs, alors que TAOUT couvre un large éventail de sujets tels que le test de double, de stratégies, de maintenance, etc. Soit le livre est bon; cela dépend de ce que vous voulez de lui.

Aussi, voici un lien vers une conférence Roy Osherove fait sur les tests unitaires. Il vaut la peine de regarder (certains de la révision de l'examen des vidéos, il a enregistré, comme il le souligne divers problèmes de dos/à ne pas faire avec les raisons).

Comment faire pour démarrer

Il n'y a rien de mieux que d'écrire du code. Trouver un assez simple classe qui n'a pas de référence d'autre chose. Ensuite, commencez à écrire des tests.

Demandez-vous toujours "ce que je veux essayer de prouver avec ce test?" avant de vous l'écrire, puis donnez-lui un nom décent (impliquant généralement de la méthode appelée, le scénario et le résultat attendu, par exemple, sur une pile: "Pop WhenStackIsEmpty ThrowsException").

Pensez à toutes les entrées que vous pouvez jeter à elle, différentes combinaisons de méthodes susceptibles de produire des résultats intéressants et ainsi de suite.

Answer 2

Si vous êtes curieux au sujet de l'unité de tester la meilleure façon d'apprendre c'est de l'essayer. Vous aurez probablement commencer à écrire des tests d'intégration au premier abord, mais c'est très bien. Quand ils semblent trop difficiles à maintenir ou trop de travail pour écrire, lire plus sur ce type de tests il y a (unitaires, fonctionnels, d'intégration) et essayez d'apprendre à connaître la différence.

Si vous êtes intéressé à démarrer avec TDD, l'Oncle Bob est une bonne source. Particalulary cette.

Plus sur les tests unitaires

S'assurer que vous obtenez la cohérence des résultats de test. Exécutant le même test à plusieurs reprises doit renvoyer le même résultat de manière cohérente.

Les tests ne doivent pas nécessiter de configuration.

Ordonnance de dépistage ne devrait pas d'importance. Cela signifie partielle des essais peuvent travailler correctement. Aussi, si vous gardez cette conception de la philosophie de l'esprit, il sera probablement aider dans votre création de tests.

Rappelez-vous que toute évaluation est mieux que pas de test. La difficulté peut être trouvé dans la rédaction d'un bon nettoyage des tests unitaires qui favorisent la facilité de création et d'entretien. Le plus difficile le cadre de tests, plus d'opposition, il y aura à l'employer. Le test est votre ami.

Answer 3

En C# et visual studio je trouve suivant une procédure très utile:

1. Pensez! Faire une petite avance de conception. Vous avez besoin d'avoir une image claire de ce que les classes dont vous avez besoin et la façon dont les objets doivent se rapporter les uns avec les autres. De ne se concentrer que sur une classe/objet (de la classe de l'objet que vous souhaitez mettre en œuvre) et une relation. Sinon vous vous retrouvez avec trop de poids lourd de la conception. J'ai souvent plusieurs esquisses (seulement quelques boîtes et de flèches) sur un disque de secours feuille de papier.

2. Créer la classe dans le code de production et le nom de manière appropriée.

3. Choisir un comportement de la classe que vous souhaitez mettre en œuvre et de créer une méthode de stub pour elle. Avec visual studio de création de la méthode vides talons est un morceau de gâteau.

4. Écrire un test pour elle. À cet effet, vous devez initialiser cet objet, l'appel de la méthode et de faire une assertion de vérifier le résultat. Dans le cas le plus facile l'affirmation nécessite une autre méthode de talon ou une propriété dans le code de production.

5. Compiler et de laisser le test runner vous montrer la barre rouge!

6. Code le comportement requis dans la production de code pour afficher la barre verte apparaît.

7. Passer à la prochaine comportement.

Pour cette procédure, deux choses sont très importantes:

• Vous avez besoin d'une image claire de ce que vous voulez et comment la classe/objet devrait ressembler. Au moins passer un peu de temps l'une d'elle.
• Réfléchir sur les comportements de la classe/objet. Cela permettra de faire les tests et la production de code de comportement-centric, qui est une façon naturelle de penser sur les classes/objets.

Tout d'abord un Test ou pas test de la première?

Je trouve souvent plus difficile de modernisation de tests existants du code de production. Dans la plupart des cas, cela est dû à des enchevêtrements de dépendances à d'autres objets, lorsque l'objet qui est soumis à l'essai doit être initialisé. TDD évite généralement ce, parce que vous voulez initialiser l'objet dans le cas de tests avec le moins d'effort possible. Il en résultera un très couplage lâche.

Quand j'ai rénovation tests, le doit lourde tâche est la tâche de l'initialisation de l'objet sous test. Aussi les assertions peuvent être beaucoup de travail en raison de enchevêtrements de dépendances. Pour cela, vous aurez besoin de changer le code de production et de briser les dépendances. En utilisant l'injection de dépendance correctement, cela ne devrait pas être un problème.

Answer 4

Oui, le préféré façon de faire du TDD est d'écrire le test d'abord (comme le laisse entendre le nom Test-Driven Development). Lorsque vous commencez avec TDD il peut être difficile de savoir par où commencer à écrire les tests, je vous suggère d'être pragmatique à ce sujet. Après tout, la partie la plus importante de notre travail consiste à fournir des code de travail, pas tellement la façon dont le code a été conçu.

Ainsi, vous pouvez commencer par écrire les tests de code existant. Une fois que vous obtenir un blocage de la façon dont les tests unitaires sont structurés, dont celles qui semblent faire du bon travail et que celles qui ne semblent pas si dieu, alors vous trouverez qu'il est plus facile de plonger plus dans le test-première approche. J'ai trouvé que j'écris des tests d'abord à une plus grande mesure que le temps passe. Il devient tout simplement plus naturel avec une expérience accrue.

Answer 5

Steve Sanderson a un grand article sur TDD les meilleures pratiques.

http://feeds.codeville.net/~r/SteveCodeville/~3/DWmOM3O0M2s/

Aussi, il y a un grand ensemble de tutoriels pour faire un ASP.net projet mvc qui traite de beaucoup de TDD principes (si vous n'avez pas l'esprit de l'apprentissage ASP.net MVC le long de la voie) http://www.asp.net/learn/mvc-videos/ Chercher la "Vitrine" de la série au bas de la page.

MOQ semble être le chaud moqueur cadre dernièrement, vous voudrez peut-être chercher dans ce

En résumé, essayez d'écrire un test pour valider quelque chose que vous r d'essayer d'archive, puis de mettre en œuvre le code pour le faire fonctionner.

Le modèle est connu comme le Rouge - Vert - Refactoriser. Aussi faites de votre mieux pour minimiser les dépendances afin que vos tests peuvent se concentrer sur une seule composante.

Personnellement, j'utilise Visual Studio Tests Unitaires. Je ne suis pas un hardcore TDD développeur, mais ce que j'aimerais faire, c'est ceci:

1. Créer un nouveau projet et de définir quelques-uns des classes fondamentales basées sur la conception du système (de cette façon, je peux au moins obtenir quelques intellisense)
2. créer une unité d'essais de projet et commencer à écrire des tests unitaires pour satisfaire les fonctionnalités que je suis en train de mettre en œuvre.
3. Les faire échouer
4. Faire passer (mettre en œuvre)
5. Refactoriser
6. Répétez, essayez de faire le test plus strictes ou de créer plus de tests jusqu'à ce que je sens sa solide.

Je me sens également très utile pour ajouter des fonctionnalités sur une sortie de la base de code. Si vous voulez ajouter une nouvelle fonctionnalité, créez d'abord le test de l'unité de ce que vous souhaitez ajouter, de parcourir le code pour voir ce que vous avez à modifier, puis passez par le processus TDD.