Question - Si je commence une demande de formulaires Windows en C # à l'aide de Visual Studio 2008, quel cadre de test unitaire devrais-je utiliser?
Il semble y avoir une construction dans VS2008? Ou devrais-je regarder quelque chose comme la renaissance? Ou est-il Nunit ce qui est utilisé dans VS2008 sous le capot? Quels sont les plus populaires.
serait bon d'avoir quelque chose qui permet: (a) moqueurs / talons, et (b) la capacité d'affirmer des exceptions
merci
6 Réponses :
Je dirais, pour la simplicité, commencez par celui intégré à Visual Studio 2008. Nunit est fantastique et je l'utilise beaucoup, vous pouvez donc probablement passer à Nunit une fois que vous êtes confortable avec des tests d'unité d'écriture.
Les tests Unitaires VS2008 vous permettent-ils d'affirmer qu'une exception devrait se produire? Je ne peux même pas vraiment voir ça?
Oui, bien que vous le fassiez avec un attribut ([attente d'accusation ()], je crois)
Je recommanderais d'utiliser Nunit pour votre cadre de test. C'est très léger et facile à expédier si vous devez le faire installer sur un serveur de construction. Ce n'est pas le cas avec Mstest. En ce qui concerne les cadres moqueurs / isolation, Rhino Mocks possède la plus grande base d'utilisateurs et vous trouverez probablement des réponses à vos questions rapidement avec les moqueurs de Rhino.
Le plus gros inconvénient avec Mstest est une fois que vous avez commencé cette route, il est difficile de changer d'avis. Nunit est un peu plus facile à convertir en Mstest. Essayez-les tous les deux.
S'il s'agit simplement d'une application simple, le cadre Mstest intégré à VS2008 devrait cocher toutes les cases. Ce n'est pas la même chose que la Nunit, bien que beaucoup de gens (à tort) se rapportent comme si elles étaient la même chose.
Je ne l'ai jamais utilisé pour se moquer, alors peut-être que quelqu'un d'autre peut élaborer à ce sujet. Il génère un projet séparé dans votre solution qui est juste dans le but de tester. C'est une bonne explication de la façon de l'utiliser.
c'est à partir de l'article de comparaison que j'ai lié à.
Je n'ai jamais utilisé de Nunit, seulement Mstest pour C # et Junit pour Java, alors je suis un peu biaisé à cet égard. Mstest a toujours très bien fonctionné pour moi sauf si vous avez une raison particulière de prendre l'approche Nunit / Testdriven.net, comme si vous avez besoin d'une fonctionnalité donnée ou que vous préférez simplement ce mode de mise en place de tests et d'essayer de l'intégrer à VS, puis je ne le fais pas Voir n'importe quelle raison de ne pas utiliser Mstest qui fonctionne dès la sortie de la boîte. 
(source: geekzone.co.nz )
Semble injuste quand beaucoup de gens utilisent Testdriven.net pour conduire Nunit. Cela fournit une grande intégration et supprime la plupart des inconvénients que vous mentionnez. L'attribut Nunit [Ignorer] désactive les méthodes [Test] ou les classes [TestFixture]. En outre, les cas de test de commande IMHO sont un peu malodorants :)
Aie. 600 caractères ne vont pas suffire. 1. C'est bien. Je peux exécuter mes tests sur n'importe quelle machine (construction / qa) sans avoir à installer VSTS. 2. Si vous souhaitez cliquer avec le bouton droit de la souris et exécutez des tests, obtenez des add-ins de Resharper / Testdriven.net. Voir aussi q # 196740. # 3,4,6,10 - n'a pas de sens. Je crois que les programmeurs connaissent leur code mieux que vs. Il s'ensuit qu'ils peuvent mieux identifier les tests à écrire. Mais alors je suis infecté par le test (lu TDD Zealot). Les cas de test ne doivent pas dépendre de l'ordre - donc pas sûr pourquoi c'est un désavantage.
Cond ... Les cas de test de débogage peuvent être effectués (Ajouter Nunit en tant que EXE externe à déboguer pour votre DLL de test); Bien que cela implique que vous ne connaissez plus votre code. Tri des cas de test - encore une fois, ne savez pas pourquoi vous en avez besoin. Mais vous pouvez regrouper vos tests en catégories telles que [catégorie ("tests lents")], puis inclure ou les exclure des essais. Vous avez également une vue sur la case à cocher où vous pouvez effectuer des tests manuellement que vous souhaitez exécuter. Enfin 9. StackTrace - Nunit fait cela dans le premier onglet. Un cadre de test unitaire serait un peu criblé s'il n'a pas indiqué que l'emplacement exact où le test a échoué!
"L'installation de Nunit vient dans un MSI séparé." Vous pouvez simplement faire référence à l'Assemblée d'un projet. C'est comme ça que je l'utilise toujours.
-1 Puisque tant de "faits" sont tout simplement faux (comme l'ont déjà signalé dans d'autres commentaires).
Je suis aussi une personne TDD, je vois que cette réponse a été votée à plusieurs reprises. Je ne voulais pas bouleverser les fanatiques des nunites uniques, expliquez simplement ce que j'ai utilisé et pourquoi cela fonctionne pour moi spécialement pour les applications WinForms. La comparaison vient du site que j'ai lié à. En dehors de Gishu qui dit que Nunit peut effectivement imprimer une standingTrace lorsqu'un test échoue (qui semble un peu critique), les autres ne sont que des opinions ou des justifications pour la raison pour laquelle les nunites font les choses différemment.
Cette description semble incroyablement biaisée. Avoir à écrire votre témoignage n'est pas un inconvénient! Qui semble aussi logique que de dire qu'il faut écrire du code pour écrire du code est un inconvénient.
Nous avons commencé avec Mstest. Il a un avantage qui est (légèrement) difficile à reproduire en nunit. Cela vous permet d'accéder aux membres privés de la classe. Ceci est inestimable lorsque vous vérifiez l'état. Par exemple, disons que j'ai une fonction qui met les entrées dans un dictionnaire qui n'est pas exposé. Ma compréhension, c'est qu'avec Nunit, vous devez utiliser la réflexion pour atteindre le dictionnaire ou ajouter un getter dans le seul but de tester. Ici, vous pouvez simplement vérifier le dictionnaire. Très facile et très propre. Cela vous permet également de tester des fonctions privées que j'aime (je sais que certaines personnes ne croient pas en cela). Pendant que je n'aime pas le Mstest, cette fonctionnalité facilite beaucoup les tests.
L'intégration vs est également agréable.
Comment Mstest réalise-t-il les "membres d'accès privé" Steve savez-vous? juste intéressé par la raison pour laquelle il serait facile pour les gars de Mstest de fournir ceci mais pas les gars de Nunit
Je crois comprendre que les nunit les gars n'y croient pas. Avec Mstest, vous avez juste un clic droit dans la classe que vous souhaitez tester et choisir "Ajouter une classe Accessor". Vous accédez ensuite à la classe FOO comme FOO_Accessor dans votre test.
Mon groupe est relativement nouveau dans les tests unitaires et il y avait beaucoup de choses que nous avons aimé sur Nunit, mais le truc de l'accesseur privé était un disjoncteur de l'affaire.
C'est aussi un disjoncteur d'encapsulation .. Vous marchez directement dans un anti-motif - visitez Stackoverflow.com/Questtions/333682/TDD-ANTI-Patterns-Catalog ue et rechercher l'inspecteur. Nunit fait la bonne chose en ne soutenant pas cela.
Nous pouvons accepter de ne pas être d'accord sur celui-ci. Mes cours tient des trucs et ont un état. J'ai besoin de trouver un moyen de vérifier cet état sans appeler d'autres fonctions (si je peux l'aider). J'ai écrit les classes "parfaites" où toutes les fonctions sont autonomes et ont peu / pas d'état, mais je n'ai pas pu le faire pour des cours qui font réellement des choses.
Ne pas essayer d'être dogmatique. Si vous n'avez pas déjà lu ceci, jetez un coup d'oeil - pragprrog.com/articles/tell- ne demandez pas . Regardant à l'intérieur d'une classe pour regarder son état - fait des tests fragiles. Votre test a maintenant une connaissance de niveau de mise en œuvre. Les tests doivent indiquer quoi (et non). Le risque ici est que les refacteurs futurs par ex. Modification du type de variable détenant l'état ou son nom - Tests de rupture. D'où le terme tests fragiles ou fragiles. Le comportement n'est pas cassé mais les tests échoueraient toujours.
Utilisez Mstest. Il est intégré à VS2008 et a pris en charge l'IDE pour créer des fonctions de test. Si et lorsque vous "dépassez" Mstest, vous devriez alors regarder Nunit ou plus moderne Xunit . Vous pouvez vous attendre à des exceptions à Mstest en décorant avec l'attribut attenduException.
[Test]
[ExpectedException(typeof(ArgumentNullException))]
public void Should_throw_ArgumentNullException_when_the_Order_is_null()
{
OrderProcessor processor = new OrderProcessor();
processor.ProcessOrder(null);
}
Avec certitude. Et vous pouvez également exécuter Nunit de Visual Studio si vous avez Resharper.
Mstest n'utilise pas l'attribut [Test]. Ceci est utilisé dans Nunit et Mbunit, qui rend ces deux interchangeables, également un bonus pour n'utiliser pas le MSST, vous êtes plus fortement attaché dans un cadre.
Vous n'avez pas mentionné si vous alliez être du code de conduite de test ..
Je recommanderais d'obtenir un livre mince 'Test de l'unité pragmatique en C # avec Nunit' et le traversant au moins une fois.
sur la nunit v mstsest Line, je ne suis pas apte à commenter. 0 Heure de vol avec Mstest.