Projets de test NUnit vs Visual Studio 2008 pour les tests unitaires?

Je vais lancer un nouveau projet au travail et je veux passer aux tests unitaires. Nous utiliserons VS 2008, C # et les éléments ASP.NET MVC. Je cherche à utiliser NUnit ou les projets de test intégrés à VS2008, mais je suis ouvert à d’autres recherches. Est-ce qu’un système est 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.

Merci pour toute aide et suggestions !!

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

  • NUnit a un cadre moqueur.
  • NUnit peut être exécuté en dehors de l’EDI, cela peut être utile si vous souhaitez exécuter des tests sur un serveur de compilation autre que MS, tel que CC.Net.
  • NUnit a plus de versions à venir que Visual Studio. Vous n’avez pas à attendre des années pour une nouvelle version Et vous n’avez pas besoin d’installer une nouvelle version de l’IDE pour obtenir de nouvelles fonctionnalités.
  • Il y a des extensions en cours de développement pour NUnit comme les tests de ligne, etc.
  • Les tests Visual Studio prennent beaucoup de temps à démarrer pour une raison quelconque. C’est mieux en 2008 mais toujours trop lent à mon goût. Effectuer 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 depuis l’IDE est en réalité beaucoup plus rapide. en particulier lors de l’exécution de tests simples.
    Accompagnant Kjetil Klaussen, cela est dû à Visual Studio Testrunner, qui exécute les tests MSTest dans TestDriven.Net rend les performances de MSTest comparables à celles de NUnit.

Le framework de test d’unité n’a pas beaucoup 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
   en utilisant Microsoft.VisualStudio.TestTools.UnitTesting;
  #autre
   en utilisant NUnit.Framework;
   en utilisant TestClass = NUnit.Framework.TestFixtureAtsortingbute;
   using TestMethod = NUnit.Framework.TestAtsortingbute;
   en utilisant TestInitialize = NUnit.Framework.SetUpAtsortingbute;
   en utilisant TestCleanup = NUnit.Framework.TearDownAtsortingbute;
   en utilisant TestContext = System.Ssortingng;
   using DeploymentItem = NUnit.Framework.DescriptionAtsortingbute;
  #fin si

Le plugin TestDriven.Net est sympa et pas très cher … Avec seulement VS2008, vous devez trouver le test de votre classe de test ou de 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.

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

  1. La version 2008 est maintenant disponible en éditions professionnelles (avant de nécessiter des versions coûteuses de VS, ceci est uniquement pour les tests unitaires de développeurs), ce qui laissait beaucoup de développeurs avec le seul choix de frameworks 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 aussi MSTest)
  4. Conception simple (sans structure Mock, mais c’est un excellent sharepoint départ pour de nombreux programmeurs)
  5. Support à long terme accordé (je me souviens encore de ce qui est arrivé à nDoc, je ne veux pas m’engager dans une infrastructure de test qui pourrait ne pas être prise en charge dans 5 ans, mais je considère toujours nUnit comme une infrastructure géniale.)
  6. Si vous utilisez le serveur Team Foundation en tant que 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.

J’utilise NUnit depuis 2 ans. Tout va bien, mais je dois dire que le système Unit de VS est plutôt sympa car il se trouve à l’intérieur de l’interface graphique et peut plus facilement tester la fonction privée sans avoir à perdre son temps. En outre, les tests unitaires de VS vous permettent de couvrir et d’autres choses que NUnit ne peut pas faire seule.

Un léger désagrément de la structure de test de Visual Studio est qu’elle créera de nombreux fichiers d’exécution de test qui ont tendance à encombrer le répertoire de votre projet, même si ce n’est pas une grosse affaire.

De même, si vous ne disposez pas d’un plug-in 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 intégré.

Légèrement hors sujet, mais si vous utilisez NUnit, je peux recommander l’utilisation de ReSharper – il ajoute des boutons à l’interface utilisateur de VS qui facilitent l’exécution et le débogage des tests depuis l’EDI.

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

XUnit est une autre possibilité pour un projet Greenfield. Sa syntaxe est peut-être plus intuitive, mais n’est pas vraiment compatible avec les autres frameworks.

http://www.codeplex.com/xunit

Mon principal bœuf avec les tests unitaires VS sur NUnit est que la création du test VS a tendance à injecter un tas de code généré pour un access membre privé.

Certains pourraient vouloir tester leurs méthodes privées, d’autres pas, c’est un sujet différent.

Mon souci 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é.

J’ai fait des TDD en utilisant les deux et (peut-être que je suis un peu bête) 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’atsortingbuts, partout – le code qui fait les tests réels est les lignes minuscules que vous pouvez lire ici et là. Un gros désordre. Dans nUnit, le code qui fait le test domine les atsortingbuts, comme il se doit.

En outre, 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 dans une vue.

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

Mais je peux me tromper, bien sûr – je viens de lire environ 21 articles sur “Comment faire du TDD simple en utilisant VSTS”. J’aurais dû lire plus, vous avez raison.

Pour nUnit, j’en lis un. Et j’étais TDDing le même jour. Avec plaisir

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 des TDD et des éléments de travail dans Visual Studio Team System est vraiment désagréable.

Bonne chance. Sylvain.

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 de fichier NUnit, vous pouvez utiliser cette solution dans un autre sens (NUnit-> VS):

#if !MSTEST using NUnit.Framework; #else using Microsoft.VisualStudio.TestTools.UnitTesting; using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAtsortingbute; using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAtsortingbute; using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAtsortingbute; using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAtsortingbute; #endif 

Ou toute autre conversion … 🙂 Cette utilisation est juste un alias pour comstackr.

Tout d’abord, je veux corriger une déclaration erronée: 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 deviendra plus populaire). Dans mon projet actuel, nous utilisons les deux et la seule grande différence que nous avons trouvée est que mstest fonctionne toujours en 32 bits alors que NUnit fonctionne en test 32 bits ou 64 bits, uniquement si votre code utilise un code natif 32/64.

J’ai commencé avec MSTest mais j’ai changé pour une raison simple. MSTest ne prend pas en charge l’inheritance des méthodes de test des autres assemblages.

Je détestais l’idée d’écrire plusieurs fois le même test. Surtout dans un grand projet où les méthodes de test peuvent facilement se heurter à des centaines de tests.

NUnit fait exactement ce dont j’ai besoin. La seule chose qui manque avec NUnit est un Addin Visual Studio qui peut afficher le statut Rouge / Vert (Comme VSTS) de chaque test.

Conseils sur les frameworks de test .NET et packages de tests unitaires .NET? .

Si vous envisagez MSTest ou nUnit, alors je vous recommande de regarder mbUnit. Mes raisons sont

  1. Compatibilité TestDriven.Net. Rien ne vaut TestDriven.Net.ReRunWithDebugger lié à une combinaison de touches.
  2. Le cadre Gallio. Gallio est un testeur comme nUnits. La seule différence est que cela ne vous dérange pas si vous avez écrit vos tests dans nUnit, msTest, xUnit ou mbUnit. Ils sont tous courus.
  3. Compatibilité avec nUnit. Toutes les fonctionnalités de nUnit sont supscopes par mbUnit. Je pense que vous n’avez même pas besoin de changer vos atsortingbuts (vous 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 jeux de données et obtenir un test pour toutes les combinaisons de données. C’est dans mbUnit.

J’ai initialement 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 ne l’ai jamais regretté. Depuis lors, j’ai converti deux équipes de développement différentes en avantages.

Pour autant que je sache, il existe actuellement quatre frameworks pour les tests unitaires avec .NET

  • NUnit
  • MbUnit
  • MSTest
  • xUnit

NUnit a toujours été en tête, mais le déficit a été 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 commencez tout juste à tester l’unité, cela ne fait probablement pas beaucoup de différence. Une fois que vous êtes à jour, vous serez mieux en mesure de juger quel cadre est le mieux adapté à vos besoins.

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

MSTest est essentiellement NUnit légèrement retravaillé, avec quelques nouvelles fonctionnalités (telles que la configuration et le déassembly des assemblages, pas seulement le niveau de assembly et de test), et certains des meilleurs bits (comme la nouvelle syntaxe de contrainte 2.4). NUnit est plus mature et les autres fournisseurs le soutiennent davantage. et bien sûr, comme il a toujours été gratuit (alors que MSTest n’a fait son entrée que dans la version professionnelle de 2008, avant qu’il ne soit plus coûteux que des références), la plupart des projets ALT.NET l’utilisent.

Cela dit, certaines entresockets sont incroyablement réticentes à utiliser quelque chose qui n’a pas le label Microsoft, en particulier le code OSS. Avoir un cadre de test MS officiel peut donc être la motivation de ces entresockets pour obtenir des tests; et soyons honnêtes, ce sont les tests qui comptent, et non l’outil que vous utilisez (et en utilisant le code de Tuomas Hietanen ci-dessus, vous pouvez presque rendre votre framework de test interchangeable).

Avec la publication dans .NET 4.0 du système de contrats de code et la disponibilité d’un vérificateur statique , vous devrez théoriquement rédiger moins de cas de test et un outil tel que Pex aidera à identifier ces cas. En rapportant cela à la discussion en cours, 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 pièces intégrées car c’est une dépendance de moins à gérer. Ces jours-ci, je suis tout au sujet de la simplicité. 🙂

Voir également:

  • Microsoft Pex – Tests unitaires automatisés
  • Génération de tests unitaires avec Pex à l’aide de Visual Studio 2010 et C # 4.0

Je préférerais utiliser le petit cadre de test de MS, mais pour le moment, je m’en tiens à NUnit. Les problèmes avec les MS sont généralement (pour moi)

  • Fichier “tests” partagé (inutile) à conserver
  • Les listes de tests provoquent des conflits avec plusieurs développeurs / VCS
  • Interface utilisateur intégrée médiocre – configuration confuse, sélection de test fastidieuse
  • Pas de bon coureur externe

Mises en garde – Si je testais un site aspx, j’utiliserais certainement les MS – Si je développais en solo, MS irait aussi bien – Si j’avais des compétences limitées et ne pouvais pas configurer NUnit 🙂

Je trouve beaucoup plus facile d’écrire mes tests et de lancer NUnitGUI ou l’un des autres frontaux (TestDriven est beaucoup trop cher). Configurer le débogage avec la version en ligne de commande est également très simple.