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.
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
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:
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.
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
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 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:
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)
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.