Comment faciliter TDD avec MSTest / VS2008

Question

J'ai lu maintes et maintes fois que TDD/test d'abord est plus difficile avec MSTest qu'avec d'autres frameworks de test tels que nUnit, MBUnit, etc...Quelles solutions de contournement manuelles et/ou éléments tiers suggérez-vous lorsque MSTest est la seule option en raison de la politique d'infrastructure ?Je m'interroge principalement sur VS 2008 Team Suite, mais je suppose que des conseils pour VS 2008 Pro conviendraient également, car certaines fonctionnalités MSTest sont désormais également incluses dans ces versions.

Answer 1

MSTest n'est certainement pas aussi efficace ou extensible que certains frameworks open source, mais il est réalisable.Puisque la question porte sur la manière de faciliter la vie avec MSTest et non sur les alternatives, voici mes conseils MSTest.

• Raccourcis.Comme l'a dit Haacked, prenez quelques secondes pour apprendre les raccourcis.
• Contexte actuel.Étant donné que MSTest est très lent, exécutez les tests uniquement dans le contexte actuel lorsque vous le pouvez.(CTRL+R., CTRL+T).Si votre curseur se trouve dans une méthode de test, cela exécutera uniquement la méthode.Si votre curseur se trouve en dehors d’une méthode, mais dans une classe de test, cela exécutera uniquement le test.Et avec un espace de noms, etc.
• Tests et organisation efficaces.C'est lent comme un chien.Faites les choses du mieux que vous pouvez en écrivant des tests efficaces.Déplacez les tests lents vers d’autres classes ou projets de test afin de pouvoir exécuter les tests rapides plus fréquemment.
• Test avec WCF.Si vous testez des services, veillez à DÉBUGER les tests plutôt qu'à les EXÉCUTER afin que Visual Studio puisse lancer les serveurs Web de développement ASP.NET.Une fois ceux-ci terminés, vous pouvez revenir à RUN, mais il peut être plus facile de toujours DÉBUGER pour ne pas avoir à y penser.
• Fichiers de configuration.Modifiez votre configuration de test pour déplacer les fichiers .config dans le dossier d'exécution du test.
• Intégration avec Source Safe.Vous devez être conscient que MSTest déteste SourceSafe et que ce sentiment est réciproque.Étant donné que MSTest souhaite placer les fichiers de test sous contrôle de code source et les ajouter à la solution, il doit extraire la solution à chaque fois que vous exécutez des tests.SourceSafe doit donc fonctionner en mode multi-extraction pour éviter de tuer vos collègues développeurs.
• Ignorer les peluches Avec MSTest, vous obtenez une douzaine de fenêtres et de vues différentes.Exécutions de tests, vue des tests, listes de tests...ils ne sont pas tous très utiles.Tenez-vous-en aux résultats des tests et vous serez beaucoup plus heureux.
• Tenez-vous-en aux « tests unitaires ».Lorsque vous ajoutez un nouveau test, vous pouvez ajouter un test ordonné, un test unitaire ou exécuter via un assistant.Tenez-vous en aux tests unitaires simples et simples.

Answer 2

Si vous n'avez pas d'autre choix que d'utiliser MSTest, apprenez les raccourcis clavier.Ils vous rendront la vie un peu plus facile.

Test dans le contexte actuel : CTRL+R., T
Tous les tests en solution : CTRL+R., UN

Tests de débogage dans le contexte actuel : CTRL+R., CTRL+T
Déboguer tous les tests dans la solution : CTRL+R., CTRL+UN

Answer 3

Je suis curieux ici.Ce que je ne comprends pas, c'est que les gens commencent à comparer tous les outils Open Source disponibles avec MSTest et commencent à le dénigrer.Commentant à quel point c'est lourd, à quel point il est peu intuitif, etc.À mon humble avis, c'est parce que c'est fondamentalement différent des frameworks xUnit.Il est optimisé pour une exécution parallèle.

Même le problème d'avoir ClassInitialze et Cleanup statiques et d'avoir un TestContext unique pour chacun des tests, tout cela à cause de la nouvelle génération - du moins pour les programmeurs professionnels Windows dans les langages MS - des concepts de programmation parallèles.

J'ai eu la malchance de travailler sur un projet comportant des dizaines de milliers de tests unitaires.Auparavant, ils prenaient pratiquement la majeure partie du temps de construction !Avec MSTest, nous avons réduit cela à des délais très gérables.

Answer 4

Mon collègue Mike Hadlow a un assez bon résumé des raisons pour lesquelles nous détestons absolument MSTest ici.

Il a réussi à le supprimer de son projet, mais je travaille actuellement sur un projet plus vaste impliquant davantage de politiques, nous l'utilisons donc toujours.

Le résultat est que celui qui a implémenté MSTest ne comprend pas TDD.Je suis désolé de ressembler à un détracteur de M$ – je ne le suis vraiment pas.Mais je suis ennuyé de devoir supporter un très mauvais outil.

Answer 5

Je n'ai vu aucun problème sérieux avec MSTest.De quoi parles-tu concrètement ?Nous passons en fait de NUnit à MSTest.Cependant, je ne connais pas nos raisons.

Answer 6

Il existe de nombreux fichiers de configuration avec mstest, ce qui le rend moins propice.
Une autre raison pour laquelle j'ai choisi mbunit est la fonctionnalité "rollback" de mbunit.Cela vous permet d'annuler toutes les opérations de la base de données effectuées lors de ce test, afin que vous puissiez réellement effectuer des tests de circuit complet sans vous soucier de la contamination de l'étang après le test.
Manque également d'installations RowTest dans mstest.

Je suggère simplement d'exécuter mbunit en tant que dépendance dans le processus de construction, c'est assez simple de simplement le faire flotter avec votre bac et votre référence, aucune installation requise.

Answer 7

• MSTest a un « friction élevée » :Obtenir un script de construction avec Naant et Mbunit par rapport à MSTEST et MSBUILD.Pas de comparaison.
• MSTEST est lent Mbunit et Nunit sont dans mon expérience plus rapidement (Gallio peut aider ici)
• MSTEST ajoute un tas de choses dont je n'ai pas besoin comme des fichiers de configuration filaire, etc.
• MSTest ne dispose pas de l'ensemble de fonctionnalités des autres frameworks de test de système d'exploitation.consultez xUnit et MbUnit

C'est tout simplement trop difficile à utiliser et il existe de nombreuses meilleures options.

Answer 8

comme mentionné, vous devez installer l'IDE complet pour pouvoir utiliser MSTest sur une autre machine, ce qui est un peu nul.Je suppose que c'est parce qu'ils veulent s'assurer que les tests unitaires ne fonctionnent que sur les studios visuels haut de gamme et que vous ne pourrez pas les exécuter de toute autre manière.

De plus, MSTest est assez lent, car entre chaque test, il reconstruit tout le contexte de chaque test, ce qui garantit qu'un test précédent a échoué ou n'influence pas le test en cours, mais ralentit les choses.vous pouvez cependant utiliser l'indicateur /noisolation, qui exécutera tous les tests du processus MSTest - ce qui est plus rapide.Pour accélérer dans l'EDI :Dans l'ide VS, vous pouvez accéder à Outils-Options puis sélectionner Outils de test.Sélectionnez le sous-élément appelé Exécution des tests et dans la boîte de dialogue à droite, assurez-vous que la case intitulée « Conserver le moteur d'exécution des tests en cours d'exécution entre les exécutions de tests » est cochée.

Answer 9

Pour répondre à une question non pointée, ma réponse serait "Nunit ne reste probablement que de votre visage".

Clause de non-responsabilité:Je n'ai aucune expérience réelle avec la version MS de xUnit, mais j'entends des problèmes tels que "Vous devez installer l'idée gigantesque juste pour exécuter vos tests sur une machine distincte" - ce qui est un non-non total.En dehors de cela, MS a cette façon de contourner le bon chemin pour un débutant via une sorte de cloche/sifflet de l'IDE qui va à l'encontre de l'idée générale.Comme si la génération de tests à partir des cours en était une dont je me souviens il y a environ un an.cela va à l'encontre de tout l'intérêt de essai routier - votre conception est censée émerger de petites étapes de RGR :écrire un test, le faire réussir, refactoriser.Si vous utilisez cet outil, cela vous prive de toute l'expérience.

Je vais arrêter mon sermon..maintenant :)

Answer 10

Je fais du développement TDD en utilisant NUnit depuis plusieurs années et j'utilise MSTest depuis environ 4 mois maintenant en raison d'un changement de rôle.

Je ne pense pas que MSTest empêche quelqu'un de faire du TDD.Vous disposez toujours de tous les éléments essentiels dont vous avez besoin pour TDD, tels que les assertions de base et les frameworks moqueurs (j'utilise Rhino Mocks).

MSTest s'intègre étroitement à Visual Studio, le meilleur composant de cette intégration est l'outil de couverture de code intégré.

Mais il y a un certain nombre de raisons convaincantes pas pour utiliser MSTest.Les deux plus gros désagréments à mon avis sont :

1. Le manque d'options d'assertion (par rapport à NUnit)
2. Le lanceur de test lent (lent par rapport à NUnit)

Cela signifie que l'écriture d'assertions nécessite plus de code en combinaison avec un exécuteur de test lent, ce qui signifie que l'ensemble du processus est plus lent que NUnit.Les options open source bénéficient également de beaucoup plus de soutien dans la communauté.

Si vous utilisez TFS pour CI, vous devrez alors franchir quelques étapes/hacks pour que NUnit publie les résultats des tests.Exécuter des tests sur TFS avec MSTest en comparaison est très simple et direct.Si vous ne touchez pas à TFS, j'irais jusqu'au bout avec NUnit, c'est tout simplement plus agréable.