NUnit contre les projets de test de Visual Studio 2008 pour les tests unitaires?
Je vais commencer un nouveau projet au travail et je veux me lancer dans les tests unitaires. Nous utiliserons VS 2008, C # et ASP.NET MVC. Je cherche à 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.
Merci pour toute aide et suggestions !!
Daok nommé tous les pro des projets de test VS2008, voici les pro 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 non MS, tel que CC.Net.
- NUnit a plus de versions qui sortent que visual studio. Vous n'avez pas besoin d'attendre des années pour obtenir une nouvelle version et vous n'avez pas besoin d'installer une nouvelle version du IDE pour obtenir de nouvelles fonctionnalités.
- Des extensions sont en cours de développement pour NUnit, telles que les tests de lignes, etc.
- Les tests de Visual Studio mettent longtemps à démarrer pour une raison quelconque. C'est mieux en 2008 mais toujours 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 IDE est en réalité beaucoup plus rapide. Surtout lors de l'exécution de tests simples.
Selon Kjetil Klaussen, cela est dû au testrunner de Visual Studio. L'exécution des tests MSTest dans TestDriven.Net rend les performances de MSTest comparables à celles de NUnit.
Le framework de test unitaire importe peu, car vous pouvez convertir des classes de test avec des fichiers de projet séparés et une compilation conditionnelle (comme celle-ci, VS-> NUnit):
#if! NUNIT utilisant Microsoft.VisualStudio.TestTools.UnitTesting; #else utilisant NUnit.Framework; utilisant TestClass = NUnit. Framework.TestFixtureAttribute; En utilisant TestMethod = NUnit.Framework.TestAttribute; En utilisant TestInitialize = NUnit.Framework.SetUpAttribute; En utilisant TestCleanup = NUnit.Framework. ] using TestContext = System.String; utilisant DeploymentItem = NUnit.Framework.DescriptionAttribute; #endif
Le plugin TestDriven.Net est agréable et pas très cher ... Avec VS2008 uniquement, vous devez trouver le test dans votre classe ou 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 à maintenir et à proximité du développeur.
Avantages/modifications du cadre de test d'unité intégré VS2008
- La version 2008 est maintenant disponible dans les éditions professionnelles (avant de nécessiter des versions coûteuses de VS, cela ne servait qu'aux tests unitaires de développeur.), Ce qui laissait à de nombreux développeurs le seul choix de cadres de test ouverts/externes.
- API intégrée prise en charge par une seule entreprise.
- Utilisez les mêmes outils pour exécuter et créer des tests (vous pouvez les exécuter en utilisant la ligne de commande ou MSTest)
- Conception simple (sans cadre Mock, mais c’est un excellent point de départ pour de nombreux programmeurs)
- Soutien à long terme accordé (je me souviens toujours de ce qui est arrivé à nDoc, je ne souhaite pas m'engager dans un cadre de test qui pourrait ne pas être pris en charge dans 5 ans, mais je considère toujours que nUnit est un excellent cadre.)
- Si vous utilisez Team Foundation Server comme serveur principal, vous pouvez créer des éléments de travail ou des bogues avec les données de test ayant échoué.
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 fait partie du Gui et peut plus facilement tester une fonction privée sans avoir à perdre son temps. De plus, les tests unitaires de VS vous permettent de couvrir et d’autres tâches que NUnit ne peut faire à lui seul.
Un peu hors sujet, mais si vous utilisez NUnit, je peux vous recommander d'utiliser ReSharper - il ajoute des boutons à l'interface utilisateur du VS qui facilitent grandement l'exécution et le débogage des tests à partir de l'EDI.
Cet avis est légèrement obsolète, mais l'explique plus en détail:
Le framework de test de Visual Studio présente un léger inconvénient: il créera de nombreux fichiers de test qui tendent à encombrer votre répertoire de projet - bien que cela ne soit pas une grosse affaire.
En outre, 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, contrairement à la structure de test Microsoft VS intégrée.
Mon principal atout avec les tests unitaires VS sur NUnit est que 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.
Mon souci est que lorsque je rédige des tests unitaires, ils doivent être extrêmement contrôlés afin que je sache 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 quelques TDD en utilisant les deux et (peut-être que je suis un peu idiot) 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 effectue les vrais tests est constitué des lignes minuscules que vous pouvez lire ici et là. Un gros désordre. Dans nUnit, le code qui effectue le test ne fait que dominer 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 en un seul regard.
Dans VSTS, la liste de tests est coincée dans le 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 qu'un seul test (enfin, je ne l'ai pas encore découvert!).
Mais je peux me tromper, bien sûr. Je viens de lire 21 articles de blog sur "Comment faire du TDD simple en utilisant VSTS". J'aurais dû lire plus, vous avez raison.
Pour nUnit, j'en ai lu un. Et j'étais en train de partir le même jour. Avec plaisir.
En passant, j'adore les produits Microsoft. Visual Studio est vraiment le meilleur outil qu'un développeur puisse acheter - mais la gestion de TDD et d'éléments de travail dans Visual Studio Team System est vraiment nul.
Bonne chance. Sylvain.
XUnit est une autre possibilité pour un projet greenfield. Il a peut-être une syntaxe plus intuitive, mais n'est pas vraiment compatible avec les autres frameworks.
Tout d'abord, je souhaite corriger une mauvaise affirmation: vous pouvez exécuter msTest en dehors de Visual Studio à l'aide de la ligne de commande. Bien que plusieurs outils de 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 constatée est que mstest est toujours exécuté en 32 bits, tandis que NUnit est exécuté en test 32 bits ou 64 bits, ce qui n’a d’importance que si votre code utilise un code natif dépendant de 32/64.
J'ai reçu des messages indiquant que "la structure de 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 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 est juste un alias pour le compilateur.
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 des autres assemblages.
Je détestais l'idée d'écrire le même test plusieurs fois. Surtout sur un grand projet où les méthodes de test peuvent facilement être exécutées en une centaine 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.
Si vous envisagez d'utiliser MSTest ou nUnit, je vous recommande de regarder mbUnit. Mes raisons sont
- Compatibilité TestDriven.Net. Rien ne vaut TestDriven.Net.ReRunWithDebugger lié à une combinaison de clavier.
- Le cadre Gallio. Gallio est un coureur de test comme nUnits. La seule différence est que cela ne vous dérange pas que vous écriviez vos tests dans nUnit, msTest, xUnit ou mbUnit. Ils sont tous courus.
- 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 (vous devrez vérifier cela), juste votre référence et vos utilisations.
- 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.
- Tests combinatoires. Ce ne serait pas cool si vous pouviez fournir deux ensembles de données et faire un test pour toutes les combinaisons de données. C'est dans mbUnit.
À l'origine, j'avais choisi mbUnit en raison de sa fonctionnalité [RowTest ....], et je n'ai trouvé aucune raison de revenir en arrière. J'ai transféré 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.
Je n'aime pas le cadre de test intégré de VS car il vous oblige à créer un projet séparé au lieu de faire vos tests dans le cadre du projet que vous testez.
Pour autant que je sache, quatre frameworks 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 depuis un an environ. 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 êtes au courant, vous serez mieux à même de déterminer le cadre qui répond le mieux à vos besoins.
MSTest est essentiellement un peu retravaillé avec NUnit, avec quelques nouvelles fonctionnalités (telles que la configuration et le démontage de l’assemblage, et pas seulement le niveau de test et de montage), et il manque quelques-uns des meilleurs éléments (comme la nouvelle syntaxe de contrainte 2.4). NUnit est plus mature et supporté par d’autres fournisseurs; et bien sûr, puisque cela a toujours été gratuit (alors que MSTest n’était intégré que dans la version professionnelle de 2008, il était auparavant beaucoup plus coûteux), mais la plupart des projets ALT.NET l’utilisent.
Cela dit, certaines entreprises hésitent énormément à utiliser un produit qui ne porte pas le label Microsoft, notamment le code OSS. Ainsi, disposer d'un cadre de test officiel pour MS peut être la motivation dont ces entreprises ont besoin pour se faire tester. et soyons honnêtes, ce sont les tests qui importent et non pas l'outil que vous utilisez (et à l'aide de code de Tuomas Hietanen ci-dessus, vous pouvez presque rendre votre cadre de test interchangeable).
Avec la publication dans .NET 4.0 du système de contrats de code et de la disponibilité d'un vérificateur statique , il vous faudrait théoriquement écrire moins de scénarios de test et un outil comme Pex aidera à identifier ces cas. Pour en revenir à la discussion actuelle, si vous devez en faire moins avec vos tests unitaires parce que vos contrats couvrent votre compte, pourquoi ne pas simplement utiliser les éléments intégrés, car il s’agit d’une dépendance de moins à gérer. Ces jours-ci, je suis tout au sujet de simplicité. :-)
Voir également:
Je préférerais utiliser le petit cadre de test de MS, mais pour l’instant, je m'en tiens à NUnit. Les problèmes avec MS sont généralement (pour moi)
- Fichier "tests" partagé (inutile) à conserver
- Les listes de tests génèrent des conflits avec plusieurs développeurs/VCS
- Interface utilisateur médiocre - configuration confuse, sélection de tests fastidieuse
- Pas de bon coureur externe
Mises en garde - Si j’essayais de tester un site aspx, j’utiliserais définitivement MS - Si je développais en solo, je pourrais aussi utiliser MS - Si j’avais peu de ressources compétence et ne pouvait pas configurer NUnit :)
Je trouve qu'il est beaucoup plus facile d'écrire mes tests et de lancer NUnitGUI ou l'un des autres frontaux (testDriven est de loin beaucoup trop cher). Configurer le débogage avec la version en ligne de commande est également assez facile.