Contrôler l'ordre d'exécution des tests unitaires dans Visual Studio

Bon, je suis en fait à la recherche de la bonne information sur ce sujet.
J'ai une série de Tests Unitaires qui appellent une classe statique qui, une fois initialisé, définit les propriétés qui ne peuvent pas (ou je ne souhaite pas) changer.

Mon problème est que je ne peut pas appliquer un ensemble de commande pour les tests à exécuter. Si je pouvais, j'ai pu les exécuter d'une manière telle que les propriétés statiques serait fixé de manière fiable, et je pouvais Affirmer sur eux, mais malheureusement, le Microsoft.VisualStudio.TestTools.UnitTesting cadre que je viens de pistes dans un ordre apparemment aléatoire.

Donc, j'ai trouvé ce http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.priorityattribute.aspx qui est dit dans les Remarques de la section "Cet attribut n'est pas utilisé par le système de test. Il est fourni à l'utilisateur pour personnaliser fins." Hein? Qu'en est-il alors? Attendent-ils de moi pour écrire mes propres tests wrapper pour profiter de ce fabuleux attribut (dont je pourrais facilement écrire moi-même si je voulais aller à ce niveau de l'effort...)

Donc, assez de la diatribe; ligne de Fond, il est un moyen pour contrôler l'ordre dans mes tests unitaires exécuter?

[TestMethod]
[Priority(0)]

etc. ne semble PAS fonctionner, ce qui est logique, puisque Microsoft indique qu'il ne sera pas.

Aussi, s'il vous plaît pas de commentaires à propos de "violation de l'isolement". TestClass isolats de ce que je suis en train de tester, et non les Méthodes. Peu importe, chaque test peut être exécuté indépendamment seulement beaux, mais ils ne peuvent pas être exécutées dans un ordre aléatoire comme il n'existe aucun moyen d'abattre la classe statique.

Oh, je connais aussi "Test Ordonné".

  • Êtes-vous en mesure d'expliquer pourquoi vos tests sont d'ordre à charge? Je le prends les tests sont essentiellement progressivement les essais Statiques de la Classe?
  • Vos tests unitaires ne doivent pas dépendre de l'ordre. Cette mort cérébrale statique de la classe est de rendre votre code invérifiables. Si vous ne pouvez pas "tear it down", alors ce n'est pas le seul problème que vous allez avoir lors de tests unitaires.
  • La classe statique n'est pas le mien - oui, il doit avoir été écrit comme un singleton. Malheureusement, parfois, il vous suffit de jouer la (merde) les cartes qui vous sont distribuées. Je suis à l'aide de Faux autant que possible de les enlever de l'équation, mais je ne peux pas l'éliminer.
  • l'impossibilité de détruire une classe statique n'est pas une question nouvelle. Les gens semblent s'en passer. Encore une fois, je ne demande pas de commentaires sur la "mort cérébrale" cadre de, seulement si il existe un moyen de le surmonter. 🙂
  • Vous ne pouvez pas réinitialiser le statique de la classe de contexte à chaque fois dans une TestInitialize? L'un des principes de base de l'unité de test est celle de l'indépendance, n'essayez pas de contrôler l'ordre d'exécution. Vous n'êtes pas la "violation de l'isolement", mais de violer les principes de base qui fait un test un test unitaire.
  • lorsque la classe statique est "pas toi" et est privé/interne et appartient à un tiers de la bibliothèque, vous êtes littéralement vissé, à moins d'utiliser l'approche que j'ai esquissé dans ma partie-offtopic réponse. Brièvement: Domaines D'Application. Inconvénients: autochtone/non géré état fait encore mal.
  • Même si vous aviez une Méthode pour réinitialiser le stastic classe, il faudrait toujours être tous dans le même domaine d'application et de vos appels à la Reset()-Method pourrait écraser vos Tests, sauf si vous exécutez un par un.
  • Dans Visual Studio 2015, les choses ont un peu changé. Dans l'Explorateur de solutions, cliquez du bouton droit sur l'unité d'un projet de test, cliquez sur Ajouter>OrderedTest. En faisant cela ajoute un nouveau fichier au projet. Lorsque vous ouvrez ce fichier, vous aurez à cliquer sur les méthodes de test au sein de votre projet et ajouter 1 ou plusieurs fois à cette épreuve.
  • Voir mon commentaire ci-dessous sur ClassInitialize attribut, aussi je crois OrderedTests sont assez faciles à mettre en œuvre et MS sont acceptées.
  • On peut avoir beaucoup de raisons pour exécuter commandé des tests. Et quand on en a besoin pour exécuter commandé des tests, on n'a vraiment pas besoin de commentaires qui ne sont pas vraiment aider, comme de dire que vous ne devriez pas faire ça, etc. Je suis en demandant poliment que la prochaine fois, s'il vous plaît ignorer ce genre de commentaires et d'essayer d'être utile. Ou juste passer le fil complètement. Je vais ajouter ma réponse en une minute.
  • Une autre raison pourquoi je devrais être capable de définir l'ordre d'exécution des tests: je voudrais que mes tests de base pour être exécuté avant que le plus compliqué des classes, qui dépendent de l'classes de base. Je préfère voir cette dépendance au lieu d'avoir les tests en cours d'exécution par ordre alphabétique (Visual Studio 2017)

InformationsquelleAutor iGanja | 2013-12-20