NUnit vs projets de test de Visual Studio 2008 pour les tests unitaires? [fermé]


254

Je vais lancer un nouveau projet au travail et je veux me lancer dans les tests unitaires. Nous utiliserons VS 2008, C # et les trucs ASP.NET MVC. J'envisage d'utiliser NUnit ou les projets de test intégrés de VS2008, mais je suis ouvert à la recherche d'autres suggestions. Un système est-il meilleur que l'autre ou peut-être plus facile à utiliser / à comprendre que l'autre? Je cherche à faire de ce projet une sorte de «meilleure pratique» pour nos efforts de développement à l'avenir.

Merci pour toute aide et suggestions !!

Réponses:


99

Daok a nommé tous les pro des projets de test VS2008, voici les pro de NUnit.

  • NUnit a un cadre de simulation.
  • NUnit peut être exécuté en dehors de l'IDE, cela peut être utile si vous souhaitez exécuter des tests sur un serveur de build non MS comme CC.Net
  • NUnit a plus de versions qui sortent que Visual Studio. Vous n'avez pas à attendre des années pour une nouvelle version Et vous n'avez pas à installer une nouvelle version de l'IDE pour obtenir de nouvelles fonctionnalités.
  • Il existe des extensions en cours de développement pour NUnit comme les tests en ligne, etc.
  • Les tests Visual Studio prennent du temps à démarrer pour une raison quelconque. C'est mieux en 2008 mais encore trop lent à mon goût. Exécuter rapidement un test pour voir si vous n'avez pas cassé quelque chose peut prendre trop de temps. NUnit avec quelque chose comme Testdriven.Net pour exécuter des tests à partir de l'IDE est en fait beaucoup plus rapide. en particulier lors de l'exécution de tests uniques.
    Selon Kjetil Klaussen, cela est dû au testrunner Visual Studio, l'exécution de tests MSTest dans TestDriven.Net rend les performances MSTest comparables à NUnit.

19
Vous ne pouvez pas simplement utiliser mstest.exe pour exécuter des tests MSTest en dehors de l'EDI?
Phillip Wells

13
Nunit ayant un cadre moqueur n'est pas vraiment un avantage. J'ai utilisé des projets de test unitaire VS 2008 avec le framework Moq qui utilise une nouvelle approche, en exploitant les arborescences d'expression LINQ: code.google.com/p/moq
DSO

5
Un avantage de plus pour Nunit, pour moi de toute façon, est que Resharper a une très belle interface utilisateur qui est beaucoup plus rapide que les composants de test VS. Il relie même la trace de pile des tests ayant échoué à votre code.
Jeff Putz

7
Les tests unitaires sont inclus dans la version professionnelle de VS 2008.
user179700

3
@Jeff Putz: Resharper peut également exécuter les tests unitaires de Visual Studio, même en dehors d'un projet de test.
Paul Ruane

64

Le framework de tests unitaires n'a pas vraiment d'importance, car vous pouvez convertir des classes de test avec des fichiers de projet séparés et une compilation conditionnelle (comme ceci, VS-> NUnit):

 #if! NUNIT
  using Microsoft.VisualStudio.TestTools.UnitTesting;
 #autre
  using NUnit.Framework;
  using TestClass = NUnit.Framework.TestFixtureAttribute;
  using TestMethod = NUnit.Framework.TestAttribute;
  using TestInitialize = NUnit.Framework.SetUpAttribute;
  using TestCleanup = NUnit.Framework.TearDownAttribute;
  using TestContext = System.String;
  using DeploymentItem = NUnit.Framework.DescriptionAttribute;
 #fin si

Le plugin TestDriven.Net est agréable et pas très cher ... Avec seulement VS2008 ordinaire, vous devez trouver le test dans votre classe de test ou votre liste de tests. Avec TestDriven.Net, vous pouvez exécuter votre test directement à partir de la classe que vous testez. Après tout, le test unitaire doit être facile à entretenir et à proximité du développeur.


12
J'ai voté pour celui-ci parce que NUnit a une syntaxe plus riche que MSTest, ce qui signifie que vous pouvez passer de MSTest -> NUnit, mais pas l'inverse, sauf si vous êtes TRÈS prudent. L'histoire montre qu'au moins l'un d'entre nous ne l'est pas.
Thomas Eyde

2
Je suis d'accord avec Thomas. Cela fonctionnera en supposant que vous utilisez les instructions d'assertion les plus élémentaires, mais le modèle de contrainte NUnit est très puissant et une raison suffisante pour choisir NUnit plutôt que MSTest.
Mark

Je crois que cette approche est adoptée par le groupe ms pattern et practice dans les tests EntLib.
robi-y

1
@Dan Neely si vous testez des soldats privés, vous vous trompez :(
JDPeckham

2
@JDPeckham Je ne dis pas que les conventions sur ce qui devrait / ne devrait pas être fait avec un outil ne sont pas importantes, mais en fin de compte, faire le travail est la chose la plus importante. Si cela signifie frapper un clou avec le côté arrière d'une hache de guerre parce que les vendeurs d'outils ne vendent pas de marteaux, alors les fabricants de haches devront simplement vivre avec être outrés.
Dan est en train de jouer par Firelight

34

Avantages / modifications du cadre de test d'unité intégré VS2008

  1. La version 2008 est désormais disponible dans les éditions professionnelles (avant de nécessiter des versions coûteuses de VS, c'est uniquement pour les tests unitaires des développeurs), ce qui a laissé beaucoup de développeurs avec le seul choix de cadres de test ouverts / externes.
  2. API intégrée prise en charge par une seule entreprise.
  3. Utilisez les mêmes outils pour exécuter et créer des tests (vous pouvez les exécuter en utilisant la ligne de commande également MSTest)
  4. Conception simple (pas de framework Mock, mais c'est un excellent point de départ pour de nombreux programmeurs)
  5. Prise en charge à long terme accordée (je me souviens encore de ce qui est arrivé à nDoc, je ne veux pas m'engager dans un cadre de test qui pourrait ne pas être pris en charge dans 5 ans, mais je considère toujours nUnit comme un excellent cadre.)
  6. Si vous utilisez le serveur Team Foundation comme serveur principal, vous pouvez créer des éléments de travail ou des bogues avec les données de test ayant échoué de manière simple.

4
Je pense que cela dit encore sur la vision de Microsoft des tests: ce n'est PAS dans la version Standard, juste Professional et au-dessus.
J Wynia

D'accord, j'aimerais le voir en standard et en haut. Dans les versions express, ce sera exagéré pour un débutant.
Simara

1
@J Wynia: lire leur décision de l'inclure uniquement dans Professional et au-dessus comme dire quelque chose à propos de leur point de vue sur les tests, c'est y lire beaucoup trop. C'est plus probablement une décision commerciale que philosophique.
Jason

@Simara Testing doit être inhérent au cycle de vie du développement. Il devrait être fourni dans les éditions express.
Eastender

33

J'utilise NUnit depuis 2 ans. Tout va bien, mais je dois dire que le système d'unités dans VS est assez agréable car il est à l'intérieur de l'interface graphique et peut plus facilement faire un test de fonction privée sans avoir à jouer. En outre, les tests unitaires de VS vous permettent de faire de la couverture et d'autres choses que NUnit seul ne peut pas faire.


44
Vous ne devriez pas toucher vos soldats. Blague à part, une école de pensée est que tout ce dont vous avez besoin pour le test, ce sont vos méthodes publiques. L'appel de toutes vos méthodes publiques doit appeler toutes vos méthodes privées. Si une méthode privée n'est pas appelée via une méthode publique, la méthode privée est redondante.
Lieven Keersmaekers

7
@Lieven: si vous testez des particuliers avec le public, vous faites vraiment un test d'intégration et non un test unitaire. (Bien sûr, je ne suis pas un fanatique de TDD et je testerais probablement le public ... mais j'ai envie d'aider à commencer un combat)
Matthew Whited

11
@Matthew, les tests d'intégration testent deux ou plusieurs unités ensemble. Tester des méthodes privées n'est qu'une (énorme) violation de l'encapsulation et peut conduire à des tests unitaires fragiles qui doivent être modifiés à chaque fois que l'implémentation change.
Omer Rauchwerger

3
Vous pouvez également utiliser [assembly: InternalsVisibleTo (...)] avec une directive de compilation pour la supprimer lorsque vous effectuez une construction RTM.
Iain Galloway

1
Je touche mes contacts tout le temps :) Je pense qu'il est utile de tester spécifiquement les membres privés pour éviter les frais généraux liés aux tests des appelants qui nécessitent beaucoup de configuration complexe.
Crackerjack

14

Une légère contrariété du cadre de test de Visual Studio est qu'il créera de nombreux fichiers d'exécution de test qui ont tendance à encombrer le répertoire de votre projet - bien que ce ne soit pas si grave.

De plus, si vous ne disposez pas d'un plugin tel que TestDriven.NET, vous ne pouvez pas déboguer vos tests unitaires NUnit (ou MbUnit, xUnit, etc.) dans l'environnement Visual Studio, comme vous pouvez le faire avec le framework de test Microsoft VS, qui est intégré.


3
Vous pouvez déboguer les tests NUnit dans Visual Studio 2005.
Jason Short

Vous pouvez également déboguer xunit mais la façon de configurer cela n'est pas évidente (page des propriétés)
annakata

1
Vous pouvez facilement déboguer NUnit en attachant le débogueur au processus NUnit en cours d'exécution, comme l'a dit grimus. Aucun réel inconvénient ici.
Anne Schuessler

1: Nombre de tests configurables dans les paramètres VS - je le mets à un. 2: d'accord avec les commentaires ci-dessus - possible mais maladroit, 3: dans l'ensemble, je préfère l'environnement de test VS intégré.
RaoulRubin

14

Légèrement hors sujet, mais si vous optez pour NUnit, je peux recommander d'utiliser ReSharper - il ajoute quelques boutons à l'interface utilisateur VS qui facilitent considérablement l'exécution et le débogage des tests à partir de l'IDE.

Cette revue est légèrement obsolète, mais l'explique plus en détail:

http://codebetter.com/blogs/paul.laudeman/archive/2006/08/15/Using-ReSharper-as-an-essential-part-of-your-TDD-toolkit.aspx


Avec le plugin Gallio pour R #, vous pouvez également exécuter MSTest.
Kjetil Klaussen

CodeRush place des icônes sur les tests directement dans le code afin que vous puissiez exécuter un test, ou tous les tests dans une classe ou dans un espace de noms. Voir ici: community.devexpress.com/blogs/markmiller/archive/2009/11/16/…
Ryan Lundy

Resharper exécutera également les tests MSTest.
JDPeckham


11

Mon bœuf principal avec les tests unitaires VS sur NUnit est la création de test VS a tendance à injecter un tas de code généré pour l'accès des membres privés.

Certains voudront peut-être tester leurs méthodes privées, d'autres non, c'est un sujet différent.

Ma préoccupation est que lorsque j'écris des tests unitaires, ils doivent être extrêmement contrôlés, donc je sais exactement ce que je teste et comment je le teste. S'il y a du code généré automatiquement, je perds une partie de cette propriété.


11

J'ai fait un TDD en utilisant les deux et (peut-être que je suis un peu stupide) nUnit semble être beaucoup plus rapide et plus simple à utiliser pour moi. Et quand je dis beaucoup, je veux dire beaucoup.

Dans MS Test, il y a trop d'attributs partout - le code qui fait les vrais tests est les petites lignes que vous pouvez lire ici et là. Un gros désordre. Dans nUnit, le code qui effectue le test domine simplement les attributs, comme il se doit.

De plus, dans nUnit, il vous suffit de cliquer sur les tests que vous souhaitez exécuter (un seul? Tous les tests couvrant une classe? Un assemblage? La solution?). Un clic. Et la fenêtre est claire et grande. Vous obtenez des lumières vertes et rouges claires. Vous savez vraiment ce qui se passe d'un seul coup.

Dans VSTS, la liste des tests est bloquée en bas de l'écran, elle est petite et moche. Vous devez regarder deux fois pour savoir ce qui s'est passé. Et vous ne pouvez pas exécuter un seul test (enfin, je ne l'ai pas encore découvert!).

Mais je peux me tromper, bien sûr - je viens de lire environ 21 articles de blog sur "Comment faire du TDD simple en utilisant VSTS". J'aurais dû lire plus, tu as raison.

Pour nUnit, j'en ai lu un. Et j'étais TDDing le même jour. Avec plaisir.

Soit dit en passant, j'aime généralement les produits Microsoft. Visual Studio est vraiment le meilleur outil qu'un développeur puisse acheter - mais la gestion TDD et Work Item dans Visual Studio Team System est vraiment nul.

Bonne chance. Sylvain.


9

J'ai reçu des messages indiquant que "la structure du fichier NUnit est plus riche que VSTest" ... Bien sûr, si vous préférez la structure du fichier NUnit, vous pouvez utiliser cette solution dans l'autre sens, comme ceci (NUnit-> VS):

 #if !MSTEST
  using NUnit.Framework;
 #else
  using Microsoft.VisualStudio.TestTools.UnitTesting;
  using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
  using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
  using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
  using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAttribute;
 #endif

Ou toute autre conversion ... :-) Cette utilisation ici n'est qu'un alias du compilateur.


1
Je ne comprends pas ce que vous dites ici.
PositiveGuy

aucune configuration / démontage de niveau de luminaire :( ou supposent-ils que nous utilisons ctor et dtor?
JDPeckham

9

Je veux d'abord corriger une mauvaise déclaration: vous pouvez exécuter msTest en dehors de Visual Studio en utilisant la ligne de commande. Bien que plusieurs outils CI tels que TeamCity prennent mieux en charge NUnit (cela changerait probablement à mesure que msTest deviendrait plus populaire). Dans mon projet actuel, nous utilisons les deux et la seule grande différence que nous avons constatée est que mstest s'exécute toujours en 32 bits tandis que NUnit s'exécute en tant que test 32 bits ou 64 bits, ce qui n'a d'importance que si votre code utilise du code natif dépendant de 32/64.


8

J'ai commencé avec MSTest, mais j'ai changé pour une raison simple. MSTest ne prend pas en charge l'héritage des méthodes de test à partir d'autres assemblys.

J'ai détesté l'idée d'écrire plusieurs fois le même test. Surtout sur un grand projet où les méthodes de test peuvent facilement atteindre des centaines de tests.

NUnit fait exactement ce dont j'ai besoin. La seule chose qui manque avec NUnit est un complément Visual Studio qui peut afficher l'état rouge / vert (comme VSTS) de chaque test.



7

Si vous envisagez d'utiliser MSTest ou nUnit, je vous recommande de consulter mbUnit. Mes raisons sont

  1. Compatibilité TestDriven.Net. Rien ne vaut que TestDriven.Net.ReRunWithDebugger lié à une combinaison de clavier.
  2. Le cadre Gallio. Gallio est un testeur comme nUnits. La seule différence est que peu importe si vous avez écrit vos tests dans nUnit, msTest, xUnit ou mbUnit. Ils se sont tous enfuis.
  3. Compatibilité avec nUnit. Toutes les fonctionnalités de nUnit sont prises en charge par mbUnit. Je pense que vous n'avez même pas besoin de changer vos attributs (devrez vérifier cela), juste votre référence et vos utilisations.
  4. La collection affirme. mbUnit a plus de cas Assert, y compris la classe CollectionAssert. Fondamentalement, vous n'avez plus besoin d'écrire vos propres tests pour voir si 2 collections sont identiques.
  5. Tests combinatoires. Ce ne serait pas cool si vous pouviez fournir deux ensembles de données et obtenir un test pour toutes les combinaisons de données. C'est dans mbUnit.

À l'origine, j'ai choisi mbUnit en raison de sa fonctionnalité [RowTest ....], et je n'ai trouvé aucune raison de revenir en arrière. J'ai déplacé toutes mes suites de tests actives de nUnit, et je n'ai jamais regardé en arrière. Depuis lors, j'ai converti deux équipes de développement différentes en avantages.


6

Pour autant que je sache, il existe quatre cadres disponibles pour les tests unitaires avec .NET ces jours-ci

  • NUnit
  • MbUnit
  • MSTest
  • xUnit

NUnit a toujours été en tête, mais l'écart s'est réduit au cours de la dernière année. Je préfère toujours NUnit moi-même, d'autant plus qu'ils ont ajouté une interface fluide il y a quelque temps, ce qui rend les tests très lisibles.

Si vous débutez avec les tests unitaires, cela ne fera probablement pas beaucoup de différence. Une fois que vous serez à jour, vous serez mieux placé pour juger quel cadre est le mieux adapté à vos besoins.


6

Je n'aime pas le framework de test intégré VS car il vous oblige à créer un projet distinct au lieu d'avoir vos tests dans le cadre du projet que vous testez.


3
Vous pouvez réellement tromper Visual Studio en modifiant manuellement les fichiers de projet et en ajoutant les valeurs ProjectTypeGuids qu'il utilise pour identifier les projets de test: & lt; ProjectTypeGuids & gt; {3AC096D0-A1C2-E12C-1390-A8335801FDAB}; {FAE04EC0-301F-11D3- BF4B-00C04F79EFBC} & lt; / ProjectTypeGuids & gt;
Paul Ruane

5

MSTest est essentiellement NUnit légèrement retravaillé, avec quelques nouvelles fonctionnalités (telles que la configuration et le démontage de l'assemblage, pas seulement le niveau de montage et de test), et il manque certains des meilleurs bits (tels que la nouvelle syntaxe de contrainte 2.4). NUnit est plus mature, et il est plus pris en charge par d'autres fournisseurs; et bien sûr, comme il a toujours été gratuit (alors que MSTest n'est entré que dans la version professionnelle de 2008, avant qu'il ne soit plus cher), la plupart des projets ALT.NET l'utilisent.

Cela dit, certaines entreprises sont extrêmement réticentes à utiliser quelque chose qui ne porte pas l'étiquette Microsoft, et en particulier le code OSS. Donc, avoir un cadre officiel de test MS peut être la motivation dont ces entreprises ont besoin pour se faire tester; et soyons honnêtes, ce sont les tests qui importent, pas quel outil vous utilisez (et en utilisant le code de Tuomas Hietanen ci-dessus, vous pouvez presque rendre votre framework de test interchangeable).


J'adore la syntaxe de contraint de NUnit mais je pense que vous devriez lire ceci concernant les attributs SetUpet TearDown: jamesnewkirk.typepad.com/posts/2007/09/why-you-should-.html
Nobody

4

Avec la sortie en .NET 4.0 du système de contrats de code et la disponibilité d'un vérificateur statique , vous auriez théoriquement besoin d'écrire moins de cas de test et un outil comme Pex aidera à identifier ces cas. En rapport avec la discussion à portée de main, si vous devez faire moins avec vos tests unitaires parce que vos contrats couvrent votre queue, alors pourquoi ne pas simplement aller de l'avant et utiliser les éléments intégrés car c'est une dépendance de moins à gérer. Ces jours-ci, je suis tout au sujet de la simplicité. :-)

Voir également:


3

Je préférerais utiliser le petit framework de test de MS, mais pour l'instant je m'en tiens à NUnit. Les problèmes de SEP sont généralement (pour moi)

  • Fichier "tests" partagé (inutile) qui doit être maintenu
  • Les listes de tests provoquent des conflits avec plusieurs développeurs / VCS
  • Mauvaise interface utilisateur intégrée - configuration confuse, sélection de tests fastidieuse
  • Pas un bon coureur externe

Avertissements - Si je testais un site aspx, j'utiliserais certainement MS - Si je développais en solo, MS irait bien - Si j'avais des compétences limitées et ne pouvais pas configurer NUnit :)

Je trouve qu'il est beaucoup plus facile de simplement écrire mes tests et de lancer NUnitGUI ou l'un des autres frontaux (testDriven est beaucoup trop cher). La configuration du débogage avec la version en ligne de commande est également assez simple.


En ce moment, j'utilise Resharper pour exécuter les tests MS, donc cela ne me dérange pas beaucoup. Je préfère CodeRush + RefactorPro, bien que ce ne soit pas ce que nous utilisons ici. Peut-être qu'ils ont maintenant un coureur décent pour MS Test.
Andrew Backer
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.