Outils de test de Visual Studio comparés à des outils tiers

Question

Comment le testing tools de Visual Studio se compare-t-il à des frameworks tiers tels que NUnit? Y a-t-il des différences significatives?

Answer 1

Pour moi MsTest (comparant à MBUnit, NUnit et XUnit.net) est suffisant en termes de fonctionnalités. Le coureur intégré est OK, il fonctionne plus vite que le coureur de Resharper et produit une meilleure sortie (IMHO), cependant, un clic gauche sur l'item de test unitaire dans le coureur vous mène à la sortie de la source de test unitaire, est très non-intuitif et ennuyeux.

Mon plus gros problème avec MsTest actuellement est qu'il supprime tous les binaires et autres éléments de déploiement pour la session de test dans un seul dossier. C'est vraiment mauvais si vous avez plusieurs projets de test dans vos solutions avec, disons un Spring.Config différent dans chaque projet.

--UPDATE--

Un an après avoir écrit cette réponse, je suis convaincu MSTEST n'est pas la voie à suivre, non pas pour de nouveaux projets. Le plus gros problème est le manque de prise en charge de l'héritage pour les méthodes TestInitialize des classes Test. De plus, MsTest vous oblige à avoir Visual Studio installé sur le serveur de construction!

Answer 2

Considérons le test unitaire, Non, et je crois que certaines personnes de l'équipe NUnit sont allées à MS pour implémenter la fonctionnalité MS UnitTEST.

Mais l'édition de test a beaucoup d'autres fonctionnalités telles que les tests de Web et de charge.

Answer 3

Le framework de test unitaire MS a une meilleure intégration (même si vous utilisez Testdrven.NET) mais il prend du temps à charger, a des problèmes étranges quand il oublie de mettre à jour la liste de test. MS intègre également un outil de couverture.

Je suppose que le choix du bon outil dépend principalement de votre projet et de votre équipe.

Answer 4

Les outils de test unitaires et tous les autres outils de test de Visual Studio Team System Test Edition s'intègrent également bien avec Team Foundation Server. Je ne me réfère pas au contrôle de source, mais au fait qu'ils s'intègrent aux work items et à Team Build. En particulier, les statistiques sont conservées en fonction des réussites et des échecs des tests, et il existe de bons rapports prédéfinis que les responsables peuvent souhaiter consulter tous les jours pour voir comment les tests ont été effectués.