Visual Studio 2013 ne découvre pas les tests unitaires
j'ai une solution simple dans visual studio 2013 qui est composée par un projet web, un projet de bibliothèque et un projet de test d'unité. Quand j'ouvre la solution et que j'essaie d'exécuter les tests unitaires, ils ne sont pas découverts par visual studio. Pour exécuter les tests, j'essaie d'aller dans le menu et de choisir Test -> Run -> Run all tests ou en ouvrant la fenêtre test explorer. Par ceux à méthodes visual studio ne découvre pas de tests dans la solution.
créer d'abord une unité simple projet de tests et essayer d'exécuter le test, visual studio savoir découvrir le test et je peux l'exécuter. Puis, si j'ouvre ma solution précédente visual studio découvre maintenant tous les tests. J'essaie de sauver ma solution mais en la fermant et en la rouvrant, sans créer d'abord un projet de test unitaire, le studio visuel ne retrouve plus les tests. C'est un très étrange comportement que je ne sais pas pourquoi ce qui se passe.
j'avais l'habitude de travailler seul dans ce projet qui utilisait le git de contrôle à la source intégré à la fondation visual studio team. Le problème de visual studio ne pas découvrir les tests de l'unité commencent quand un nouvel élément est venu au projet et quand j'ai besoin de recréer la solution à travers le contrôle source en ligne. Avant cela, tous les tests ont toujours été découverts par visual studio.
pour la création de l'unité tests j'utilise la dll Microsoft.VisualStudio.QualityTools.UnitTestFramework. Ma version de visual studio est: Microsoft Visual Studio Express 2013 pour le Web Version 12.0.30723.00 Mise À Jour 3. Ma version de .net framework est 4.5.50938.
tous mes tests sont comme ceci:
[TestClass]
public class Service1Test
{
[TestMethod]
public void Test1()
{
Assert.IsTrue(True);
}
}
30 réponses
J'ai remarqué certaines choses que je dois faire de temps en temps pour obtenir des tests pour apparaître correctement.
-
Si votre solution est dans un lecteur protégé que vous avez besoin d'un accès administrateur pour lire/écrire, parfois seulement une partie des tests. Dans ce cas, exécutez définitivement VS en tant qu'administrateur.
-
si votre solution est 64 bits, assurez-vous que Test > paramètres de Test > L'Architecture du processeur par défaut est ensemble pour x64. Parfois il est réglé sur x86. Mettez-le sur x64, puis reconstruisez.
-
parfois, redémarrer Visual Studio Fait l'affaire parce que l'Explorateur de test redémarre.
-
n'oubliez pas de construire le projet/solution d'essai. (Si vous voulez qu'il soit construit avec le reste des projets, faites un clic droit sur votre solution > Propriétés > Propriétés de Configuration > Configuration > vérifiez le "Construire" de votre projet de test)
-
S'assurer que les essais sont dans une section
publicde votre classe d'essai
si vous utilisez NUnit, assurez-vous de télécharger L'Adaptateur NUnit en premier.
allez à outils → Extensions et mises à jour... → en ligne → rechercher"NUnit test adaptateur".
assurez-vous que votre classe d'essai est public donc il peut être trouvé. Et si vous faites référence à une autre classe, assurez-vous de la même chose.
aussi , parfois si vous n'avez pas D'assertions ou si vous ne décorez pas le test avec un [TestMethod] , un test pourrait ne pas être reconnu.
2 autres choses: 1) les tests de l'unité asynchrone agissent de façon amusante au mieux, et Aucun Au pire. Regardez cet article par Stephen Cleary et de garder de là si cela vous intéresse.
2) Si vous utilisez NUnit et que vous rencontrez les mêmes problèmes, gardez à l'esprit que C'est [TestCase] pour Nunit, au lieu de [TestMethod]
ayant dit ce qui précède, voici un article j'ai posté sur le projet de code, à la fois MSTest et NUnit , au cas où vous voulez lui donner un tour et s'assurer que vous ne manquez rien.
j'ai eu le même problème mais aucune des autres solutions n'a fonctionné. Il s'avère que J'utilisais le cadre NUnit 3 avec l'adaptateur 2.
si vous utilisez NUnit 3, Allez à Extensions et mises à jour et installez L'Adaptateur de test NUnit3.
j'ai ce problème de temps en temps. Ce qui fonctionne pour moi, c'est d'arrêter Visual Studio et d'aller dans le dossier:
%LocalAppData%\Microsoft\VisualStudio.0\ComponentModelCache
et supprimer son contenu.
une fois que vous ouvrez Visual Studio et chargez votre projet de nouveau, testez Explorer devrait contenir vos tests
les utilisateurs de XUnit peuvent remarquer que la fenêtre Test Explorer ne contient plus de liste de tests. Pour que les tests puissent être découverts à nouveau, essayez cette astuce importante , en surbrillance ci-dessous.
si vous avez des problèmes pour découvrir ou exécuter des tests, vous pouvez être victime d'une cache runner corrompue à L'intérieur de Visual Studio. Pour effacer ce cache, fermez toutes les instances de Visual Studio, puis supprimez le dossier %TEMP%\VisualStudioTestExplorerExtensions. Également faire bien sûr, votre projet n'est lié qu'à une seule version du paquet NuGet Visual Studio runner (xunit.coureur.visualstudio).
pour les futurs googleurs, j'ai eu un scénario rare qui a causé ça.
dans ma classe de base, J'avais une propriété appelée TestContext. Cela interférait avec la propriété TestContext réservée de MSTest, ce qui rendait tous mes tests cachés à VS/Resharper sauf un (qui n'héritait pas de la base).
pour moi, il était en train de changer les "configurations de la solution" en Debug (au lieu de Release).
mon problème était parce que ma méthode d'essai unitaire n'était pas nul , et il recevait des paramètres.
j'ai constaté que les méthodes d'essai unitaires marquées async void ne sont pas découvertes par L'Explorateur de test VS. Cela semble être parce que VS n'aurait aucun moyen d'attendre pour un test d'arrivée et de décider si elle a réussi ou non. Si vous avez absolument besoin d'une méthode de test pour exécuter asynchrone puis obtenir de retourner une tâche à la place comme async Task .
J'ai trouvé que cela a réglé le problème pour moi.
essayez de construire tous les projets comme MSIL (N'importe quel CPU) au lieu de x86/x64. Travaillé pour moi étrangement
alors que la solution D'AndyG fonctionne, une solution plus durable pourrait être de mettre la variable D'environnement PreferredToolArchitecture à "x64", soit par:
Comment faire de Visual Studio utiliser le natif amd64 toolchain
ou par:
- Panneau de configuration / système et Sécurité|Système / Paramètres de système avancés / Variables D'environnement
- Preferred Toolarchitecture = x64
- DefaultToolArchitecture = Native64Bit
- PROCESSOR_ARCHITECTURE = x64
- ProcessorArchitecture = x64
je faisais face au même problème et je me suis souvenu, encore une fois (cette situation s'est produite avant), que le choix de" plateforme mixte " sur le menu de la plateforme de solutions fonctionne, ainsi que les autres réponses.
j'ai réussi à ajouter le mien comme
public static void TestMethod1(){}
a commencé à fonctionner une fois que j'ai enlevé les parasites....
allez à Nuget package manager et téléchargez Nunit adaptateur comme suit.
allez dans le menu Projet > Gestionnaire de Configuration vérifiez que la plate-forme de votre projet d'essai correspond au reste du projet et qu'elle est cochée pour construire puis reconstruire.
vient de tomber sur ceci aussi bien que je n'ai pas vu un cas similaire qui était similaire au mien.
dans le fichier .csproj de mon projet d'essai, la protection des renseignements personnels de référence de NUnit était fixée à False :
<Reference Include="nunit.framework, Version=2.6.4.14350, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77, processorArchitecture=MSIL">
<HintPath>..\packages\NUnit.2.6.4\lib\nunit.framework.dll</HintPath>
<Private>False</Private>
</Reference>
après que j'ai mis <Private> à True il a fonctionné.
Vous avez juste besoin d'installer ce paquet:
NUnit TestAdapter
j'ai eu exactement le même problème.
c'était en raison de la version incompatible de NUnit que j'avais ajouté à mon projet (3.2.0) et L'Adaptateur de Test que j'avais installé (2.0.0).
pour corriger, utiliser" Outils > Extensions et mises à jour " et rechercher L'Adaptateur de test NUnit3, il a découvert mes tests après cela.
Cheers
disons simplement pour le bien de l'argument que vous devez utiliser l'architecture X64 sur votre projet de test afin que les dépendances soient construites correctement (comme dans mon cas). Vous devrez peut-être modifier l'Architecture de votre processeur par défaut dans le menu Test--paramètres de Test . Le paramétrage de ce paramètre à X64 a permis à mon explorateur de test de trouver mes tests en utilisant Microsoft.VisualStudio.TestTools.UnitTesting.
Désolé d'ajouter à la longue liste, mais j'ai eu un problème complètement différent. Tout d'abord, je voudrais mentionner que j'ai découvert mon problème en cliquant sur "exécuter tout" dans L'Explorateur de Test, puis en regardant la fenêtre de sortie construire dans Visual Studio. Vous devez le surveiller activement, car après le message disparaît.
quant à la question, il semble que pendant la numérisation des tests, la DLL est chargée et ses types de test sont énumérés. Cela provoque les références à être chargé et si une défaillance se produit au cours de ce processus, les tests ne seront pas affichées dans l'explorateur. J'avais deux problèmes empêchant le test DLL d'être chargé avec succès:
- il restait encore une redirection obligatoire dans le fichier de configuration (redirection vers une version plus basse que celle référencée dans le projet test).
- référence d'assemblage contradictoire (références de 2e Niveau ne pouvant pas être chargées). AsmSpy est btw un grand outil pour chasser pour ceux-ci.
si vous chargez une solution Visual Studio (VS communauté 2015 dans mon cas) à partir d'une solution network share ou My Documents directory qui fait partie d'une part , vous allez avoir des problèmes. Je l'ai résolu en déplaçant la solution et ses projets sous-jacents dans un dossier local.
après avoir passé 2 jours... rien de ce qui précède n'a fonctionné pour moi. La seule" solution " était: allez à Propriétés du projet -> onglet Construire. Ensuite, cliquez sur le bouton Avancé dans le coin inférieur droit de la vitre. Changez "Debug Info: "en" full " et cliquez sur OK.
Voici les captures d'écran:
je suis tombé sur le même problème. Et a enquêté et a constaté que les dll n'ont pas été construits, et les mettre dans le bon dossier. dès que j'ai changé ma configuration ils sont apparus. - les projets construisent des options, quel dossier doit être utilisé? - la configuration de construction de l'entrée de menu de construction, ils doivent être vérifiés.
qui l'a réparé pour moi.
pour le Visual Studio 2013.5, la suppression du répertoire \TestResults dans la solution a aidé. Visual Studio a corrompu le fichier mdf dans lequel il stocke les tests découverts, empêchant ainsi la découverte de tests unitaires.
assurez-vous que tous vos projets fonctionnent avec la même configuration. Sous Propriétés de votre projet = > Debug = > plate-forme dans la liste déroulante choisissez la plate-forme appropriée (pour moi c'était "N'importe quel CPU") comme déterminé à vos autres projets.
- je sais que les tests unitaires ne sont pas trouvés si la solution n'est pas construite, donc c'est quelque chose à essayer (construire la solution), mais cette solution est comme le service d'assistance demandant si votre ordinateur est branché...
- après une reconstruction propre n'a pas réglé le problème pour moi, l'exécution d'un lot complet construire a réglé.
avait le même problème; les essais ont soudainement cessé d'être découverts.
L'Adaptateur D'essaiNunit avait été désactivé d'une façon ou d'une autre. En cliquant sur Activer dans le gestionnaire d'extension, Je l'ai corrigé.
pour obtenir des tests à afficher dans la fenêtre de L'Explorateur de tests, J'ai dû installer NUnit3 test adaptateur 3.0 qui n'était pas disponible dans le Gestionnaire de paquets.
Téléchargé de https://visualstudiogallery.msdn.microsoft.com/0da0f6bd-9bb6-4ae3-87a8-537788622f2d
j'ai eu le même problème jusqu'à ce que je réalise que j'ai fait une erreur de coupe/pâte et ai laissé [Test Method] avant le test.