Visual Studio 2013 ne découvre pas les tests unitaires
J'ai une solution simple dans Visual Studio 2013 composée d'un projet Web, d'un projet de bibliothèque et d'un projet de test unitaire. Lorsque 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'accéder au menu et de choisir Test -> Exécuter -> Exécuter tous les tests ou en ouvrant la fenêtre de test Explorer. Grâce à ces méthodes, Visual Studio ne découvre aucun test dans la solution.
En créant d'abord un simple projet de tests unitaires et en essayant d'exécuter le test, Visual Studio sait découvrir le test et je peux l'exécuter. Ensuite, si j'ouvre ma solution précédente, visual studio découvre maintenant tous les tests. J'essaie de sauvegarder ma solution mais en la refermant et en la rouvrant, sans créer d'abord de projet de test unitaire, Visual Studio ne retrouve pas les tests. C'est un comportement très étrange que je ne sais pas pourquoi cela se produit.
J'avais l'habitude de travailler seul dans ce projet qui utilisait le git de contrôle de source intégré à la fondation d'équipe Visual Studio. Le problème de visual studio ne découvre pas que les tests unitaires commencent lorsqu'un nouvel élément est entré dans le projet et que je dois recréer la solution via le contrôle de code source en ligne. Avant cela, tous les tests avaient toujours été découverts par Visual Studio.
Pour la création des tests unitaires, j’utilise la DLL Microsoft.VisualStudio.QualityTools.UnitTestFramework. Ma version de Visual Studio est: Microsoft Visual Studio Express 2013 pour Web Version 12.0.30723.00 Mise à jour 3. Ma version du framework .net est 4.5.50938.
Tous mes tests sont comme ça:
[TestClass]
public class Service1Test
{
[TestMethod]
public void Test1()
{
Assert.IsTrue(True);
}
}
Certaines choses que j'ai remarquées que je dois faire de temps en temps pour que les tests apparaissent correctement.
Si votre solution se trouve sur un lecteur protégé pour lequel vous avez besoin d'un accès administrateur en lecture/écriture, il arrive parfois qu'une partie seulement des tests soit réalisée. Exécutez certainement VS en tant qu'administrateur dans ce cas.
Si votre solution est en 64 bits, assurez-vous que Test> Paramètres de test> Architecture de processeur par défaut est défini sur x64. Parfois, il est réglé sur x86. Réglez-le sur x64, puis reconstruisez.
Parfois, il suffit de redémarrer Visual Studio pour résoudre ce problème, car l’explorateur de tests redémarre.
N'oubliez pas de créer réellement le projet/solution de test. (Si vous voulez qu'il soit construit avec le reste des projets, cliquez avec le bouton droit de la souris sur votre solution> Propriétés> Propriétés de configuration> Configuration> cochez la case "Construire" de votre projet test.)
Assurez-vous que les tests sont dans une section
publicde votre classe de tests.
Si vous utilisez NUnit, assurez-vous de télécharger d'abord NUnit Adapter.
Allez à Outils → Extensions et mises à jour… → En ligne → recherchez "Adaptateur de test NUnit".
Assurez-vous que votre classe de test est public pour pouvoir la trouver. Et si vous faites référence à une autre classe, assurez-vous de la même chose.
De plus, parfois, si vous n'avez aucune assertion ou si vous ne décorez pas le test avec un [TestMethod], il se peut qu'un test ne soit pas reconnu.
Encore 2 choses: 1) Les tests unitaires asynchrones sont amusants au mieux, et aucun au pire. Jetez un oeil à cet article par Stephen Cleary et gardez-le à partir 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]
Ceci dit, voici un article J'ai posté sur le projet de code, avec les deux MSTest & NUnit, au cas où vous voudriez l'essayer et vous assurer que vous ne manquez rien.
J'avais le même problème mais aucune des autres solutions ne fonctionnait. Il s'avère que j'utilisais le framework NUnit 3 avec l'adaptateur 2.
Si vous utilisez NUnit 3, accédez à Extensions et mises à jour et installez l'adaptateur de test NUnit3.
Les utilisateurs de XUnit peuvent remarquer que la fenêtre Test Explorer ne répertorie plus de tests. Pour rendre les tests identifiables à nouveau, essayez cette astuce importante , mis en évidence ci-dessous.
Si vous rencontrez des problèmes pour découvrir ou exécuter des tests, vous pouvez être victime d'un cache de coureur corrompu dans Visual Studio. Pour effacer ce cache, fermez toutes les instances de Visual Studio, puis supprimez le dossier% TEMP%\VisualStudioTestExplorerExtensions. Assurez-vous également que votre projet est lié uniquement à une version unique du package NuGet de Visual Studio Runner (xunit.runner.visualstudio).
J'ai ce problème de temps en temps. Ce qui fonctionne pour moi est d'arrêter Visual Studio et d'aller dans le dossier:
%LocalAppData%\Microsoft\VisualStudio\12.0\ComponentModelCache
et supprimez le contenu.
Une fois que vous avez ouvert Visual Studio et rechargé votre projet, Test Explorer doit contenir vos tests.
Pour les futurs googleurs, un scénario rare en était la cause.
Sur ma classe de test de base, j'avais une propriété nommée TestContext. Cela a interféré avec la propriété réservée TestContext de MSTest, ce qui a masqué tous mes tests de VS/Resharper, sauf un (qui n'a pas hérité de la base).
Mon problème était que ma méthode de test unitaire n'était pas void et qu'elle recevait des paramètres.
J'ai trouvé que les méthodes de test unitaire marquées comme async void ne sont pas découvertes par VS Test Explorer. Cela semble être dû au fait que VS n’aurait aucun moyen d’attendre la fin d’un test et de décider s’il réussissait ou non. Si vous avez absolument besoin d'une méthode de test pour une exécution asynchrone, demandez-lui de renvoyer une tâche telle que async Task. J'ai trouvé que cela corrigeait le problème pour moi.
pour moi, cela changeait les 'configurations de solutions' en Debug (au lieu de Release). 
Essayez de construire tous les projets en tant que MSIL (Any CPU) au lieu de x86/x64. A travaillé étrangement pour moi
Bien que la solution d'AndyG fonctionne, une solution plus durable pourrait consister à définir la variable d'environnement PreferredToolArchitecture sur "x64", soit:
Comment faire en sorte que Visual Studio utilise la chaîne d'outils AMD64 native
ou par:
- Panneau de contrôle | Système et sécurité | Système | Paramètres système avancés | Variables d'environnement
- PreferredToolArchitecture = x64
- DefaultToolArchitecture = Native64Bit
- PROCESSOR_ARCHITECTURE = x64
- ProcessorArchitecture = x64
J'avais réussi à ajouter le mien comme
public static void TestMethod1(){}
commencé à travailler une fois que j'ai enlevé la statique ....
Je faisais face au même problème et je me souviens encore une fois (cette situation s’est produite auparavant) que la sélection de "Plate-forme mixte" dans le menu de la plate-forme de solutions fonctionne, ainsi que les autres réponses.
Accédez au gestionnaire de paquets Nuget et téléchargez l’adaptateur Nunit comme suit. 
Supposons simplement que vous ayez besoin d'utiliser l'architecture X64 sur votre projet de test pour que les dépendances se construisent correctement (comme dans mon cas). Vous devrez peut-être modifier votre architecture de processeur par défaut dans le menu Test - Test Settings. Définir ceci sur X64 a permis à mon test Explorer de trouver mes tests avec Microsoft.VisualStudio.TestTools.UnitTesting.
Après avoir passé 2 jours ... rien de ce qui précède n'a fonctionné pour moi. La seule "solution" était: Accédez aux propriétés du projet -> Onglet Construire. Cliquez ensuite sur le bouton Avancé dans le coin inférieur droit du volet. Remplacez "Informations de débogage" par "Complet" et cliquez sur OK.
Voici les captures d'écran: 
Vous avez juste besoin d'installer ce paquet seulement:
NUnit TestAdapter 
J'ai eu exactement le même problème.
C'était dû à une version incompatible de NUnit que j'avais ajoutée à mon projet (3.2.0) et à l'adaptateur de test que j'avais installé (2.0.0).
Pour résoudre ce problème, utilisez "Outils> Extensions et mises à jour" et recherchez l'adaptateur de test NUnit3. Il a ensuite découvert mes tests.
À votre santé
Désolé d’ajouter à la longue liste, mais j’ai eu un problème complètement différent. Tout d'abord, j'aimerais mentionner que j'ai découvert mon problème en cliquant sur "Tout exécuter" dans l'explorateur de tests, puis en regardant la fenêtre de sortie de la génération dans Visual Studio. Vous devez le regarder activement, car le message disparaît ensuite.
En ce qui concerne le problème, il semble que, lors de l'analyse des tests, la DLL soit chargée et ses types de tests énumérés. Cela entraîne le chargement des références et, en cas d'échec, les tests ne seront pas affichés dans l'explorateur. J'ai eu deux problèmes empêchant le chargement du test DLL:
- Il restait encore une redirection de liaison dans le fichier de configuration (redirection vers une version plus basse de NHiberate que celle référencée dans le projet test).
- Une référence d'assemblage en conflit (les références de 2e niveau ne pouvant pas être chargées). AsmSpy est en fait un excellent outil de recherche.
Pour que les tests s'affichent dans la fenêtre de l'explorateur de tests, j'ai dû installer NUnit3 Test Adapter 3.0, qui n'était pas disponible dans le gestionnaire de packages.
Téléchargé depuis https://visualstudiogallery.msdn.Microsoft.com/0da0f6bd-9bb6-4ae3-87a8-537788622f2d
Je me suis heurté à cela aussi bien que je n'ai pas vu un cas similaire qui était similaire au mien.
Dans le fichier .csproj de mon projet de test, la confidentialité de la référence NUnit a été définie sur 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 avoir réglé <Private> sur True cela a fonctionné.
Si vous chargez une solution Visual Studio (VS 2015 Community dans mon cas) depuis un partage résea ou répertoire Mes documents faisant partie d'un partage, vous rencontrerez ce problème. . Je l'ai résolu en déplaçant la solution et ses projets sous-jacents dans un dossier local.
allez dans le menu projet> Gestionnaire de configuration pour vérifier que votre plate-forme de projet de test correspond au reste du projet et est vérifiée pour construire puis reconstruire.
J'ai eu un problème similaire à celui-ci avec Visual Studio 2015. Dès que j'ai créé un test d'unité async Task, Visual Studio commençait à avoir des problèmes pour le découvrir, en trouver la source, et cela ne me permettait pas de le déboguer. .
Il se trouve qu'il existe un bogue avec PostSharp qui est à l'origine de ce problème et que le projet de test que j'utilisais avait PostSharp activé.
Dans mon cas, la solution consistait à désactiver PostSharp pour le projet de test unitaire, en insérant ce qui suit dans l'élément <PropertyGroup> au début du fichier de projet csproj:
<SkipPostSharp>True</SkipPostSharp>
- Je sais que les tests unitaires ne sont pas trouvés si la solution n'est pas construite, c'est donc quelque chose à essayer (Construire la solution), mais cette solution est comme le support technique qui demande si votre ordinateur est branché ...
- Après qu'une reconstruction en mode clair ne résolve pas le problème pour moi, l'exécution d'une génération complète par lots a résolu le problème.
Avait le même problème; les tests ont soudainement cessé d'être découverts.
L'adaptateur de test Nunit était devenu désactivé d'une manière ou d'une autre. En cliquant sur Activer dans le gestionnaire d'extensions, je l'ai corrigé.
Dans mon cas, j'ai dû mettre à jour deux paquets NuGet. - MSTest.TestAdapter - MSTest.TestFramework
J'ai eu le même problème avec mes tests sur TFS 2015. Le problème que j'avais était que mon test ne soit plus visible. l'adaptateur de test n'a trouvé aucun test. J'ai supprimé toutes les références pour Microsoft.VisualStudio.QualityTools.UnitTestFramework et maintenant, elles apparaissent à nouveau. J'espère que ma réponse aidera quelqu'un
Dans mon cas, le problème était que mon class était marqué comme abstract.
Supprimez simplement le mot clé abstract.
J'ai eu le même problème jusqu'à ce que je réalise que j'ai fait une erreur de couper/coller et que je me suis arrêté [Test Method] avant le test.
Une autre solution:
Ouvrez une invite de commande, tapez set et vérifiez si PROCESSOR_ARCHITECTURE est défini correctement, remplacez-le par x86 ou AMD64 si nécessaire.
Je suis tombé sur le même problème. Et enquêté et a constaté que les dll n'étaient pas construites, et mis dans le bon dossier. dès que j'ai changé ma configuration, ils sont apparus. - les options de construction de projets, quel dossier utiliser? - la configuration de construction de l'entrée de menu de construction, elles doivent être vérifiées.
cela l'a réparé pour moi.
Dans mon cas, j'ai mis à jour NUnit de 2.X à 3.X après que le pilote s’était arrêté pour aller dans [SetUp]. J'ai essayé d'installer les adaptateurs NUnit 3 de NuGet, mais cela n'a pas aidé. Ensuite, j'ai désinstallé ma version actuelle sur TestDriven (3.8) et installé 3.10 à la place. Cela a commencé à fonctionner (encore).
Assurez-vous que tous vos projets fonctionnent avec la même configuration. Dans la liste déroulante Propriétés => Débogage => Plate-forme de votre projet, choisissez la plate-forme appropriée (pour moi, il s'agissait de "Tout processeur"), comme déterminé par vos autres projets.
Pour Visual Studio 2013.5, effacer le répertoire\TestResults dans la solution a été utile. Visual Studio a corrompu le fichier mdf dans lequel il stocke les tests découverts, empêchant ainsi la découverte des tests unitaires.
Assurez-vous que le projet est marqué comme projet test. Vous pouvez le faire en ajoutant le xml ci-dessous au fichier de projet csproj.
<Project>
...
<ItemGroup>
<Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
</ItemGroup>
...
</Project>