Visual Studio 2013 ne découvre pas les tests unitaires

J'ai une solution simple dans Visual Studio 2013 qui est 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'essaye d'exécuter les tests unitaires, ils ne sont pas découverts par Visual Studio. Pour exécuter les tests, j'essaye d'aller dans le menu et de choisir Test -> Exécuter -> Exécuter tous les tests ou en ouvrant la fenêtre de l'explorateur de tests. Par 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 précédente solution, Visual Studio découvre maintenant tous les tests. J'essaye de sauvegarder 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 pas les tests. C'est un comportement très étrange dont je ne sais pas pourquoi cela se produit.

J'avais l'habitude de travailler seul dans ce projet qui utilisait le contrôle de source git intégré à la fondation de l'équipe de Visual Studio. Le problème de Visual Studio de ne pas découvrir les tests unitaires commencent quand un nouvel élément est arrivé au projet et quand j'ai besoin de recréer la solution via le contrôle de code source en ligne. Avant cela, tous les tests étaient toujours découverts par Visual Studio.

Pour créer les tests unitaires, j'utilise la dll Microsoft.VisualStudio.QualityTools.UnitTestFramework. Ma version de Visual Studio est: Microsoft Visual Studio Express 2013 pour la version Web 12.0.30723.00 Update 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); 
    } 
}

Certaines choses que j'ai remarquées que je dois faire de temps en temps pour que les tests apparaissent correctement.

1. Si votre solution se trouve dans un lecteur protégé pour lequel vous avez besoin d'un accès administrateur pour lire / écrire, parfois seule une partie des tests se produit. Exécutez définitivement VS en tant qu'administrateur dans ce cas.

2. Si votre solution est 64 bits, assurez-vous que Test> Paramètres de test> Architecture de processeur par défaut est défini sur x64. Parfois, il est défini sur x86. Réglez-le sur x64, puis reconstruisez.

3. Parfois, le simple fait de redémarrer Visual Studio fait l'affaire car l'explorateur de tests redémarrera.

4. N'oubliez pas de créer le projet / la solution de test. (Si vous souhaitez 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> cochez la case "Construire" pour votre projet de test)

5. Assurez-vous que les tests sont dans une publicsection de votre classe de test

Si vous utilisez NUnit, assurez-vous de télécharger d'abord l'adaptateur NUnit.

Allez dans Outils → Extensions et mises à jour… → En ligne → recherchez "NUnit Test Adapter".

Assurez-vous que votre classe de test est publicpour qu'elle puisse être trouvée. Et si vous faites référence à une autre classe, assurez-vous de la même chose.

De plus, parfois, si vous n'avez pas d'assertions ou que vous ne décorez pas le test avec un [TestMethod], un test peut ne pas être reconnu.

2 autres choses: 1) Les tests unitaires Async agissent au mieux de manière amusante, et pas du tout au pire. Jetez un œil à cet article de Stephen Cleary et gardez-le 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]

Cela dit, voici un article que j'ai publié sur le projet de code, avec les deux MSTest& NUnit, au cas où vous voudriez l'essayer et vous assurer de ne rien manquer.

J'ai eu le même problème mais aucune des autres solutions n'a fonctionné. 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.

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\12.0\ComponentModelCache

et supprimez-le contenu.

Une fois que vous ouvrez Visual Studio et chargez à nouveau votre projet, l'Explorateur de tests doit contenir vos tests

Les utilisateurs de XUnit peuvent remarquer que la fenêtre de l'Explorateur de tests ne répertorie plus aucun test. Pour rendre les tests détectables à nouveau, essayez cette astuce importante , mise 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 d'exécution corrompu dans Visual Studio. Pour vider ce cache, arrêtez toutes les instances de Visual Studio, puis supprimez le dossier% TEMP% \ VisualStudioTestExplorerExtensions. Assurez-vous également que votre projet n'est lié qu'à une seule version du package NuGet de Visual Studio runner (xunit.runner.visualstudio).

Pour les futurs googleurs, j'ai eu un scénario rare qui a causé cela.

Sur ma classe de test de base, j'avais une propriété nommée TestContext. Cela a interféré avec la propriété TestContext réservée de MSTest, provoquant le masquage de tous mes tests de VS / Resharper sauf un (qui n'a pas hérité de la base).

pour moi, cela changeait les «configurations de solution» en Debug (au lieu de Release).

Mon problème était que ma méthode de test unitaire n'était pas nulle et qu'elle recevait des paramètres.

J'ai constaté que les méthodes de test unitaire marquées comme async voidne sont pas découvertes par l'explorateur de tests VS. 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 a réussi ou non. Si vous avez absolument besoin d'une méthode de test pour s'exécuter de manière asynchrone, faites-la renvoyer une tâche à la place, comme async Task. J'ai trouvé que cela résolvait le problème pour moi.

Essayez de construire tous les projets en MSIL (Any CPU) au lieu de x86 / x64. A travaillé pour moi étrangement

Bien que la solution d'AndyG fonctionne, une solution plus durable pourrait être de définir la variable d'environnement PreferredToolArchitecture sur "x64", soit en:

Comment faire en sorte que Visual Studio utilise la chaîne d'outils amd64 native

ou par:

• Panneau de configuration | 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'étais confronté au même problème et je me suis souvenu, encore une fois (cette situation s'est déjà produite), que la sélection de «Plate-forme mixte» dans le menu de la plateforme de solutions fonctionne, ainsi que les autres réponses.

J'avais réussi à ajouter le mien comme

public static void TestMethod1(){}

a commencé à travailler une fois que j'ai supprimé l'électricité statique ...

Accédez au gestionnaire de packages Nuget et téléchargez Nunit Adapter comme suit.

allez dans le menu projet> Configuration Manager vérifiez que votre plate-forme de projet de test correspond au reste du projet et est cochée pour construire puis reconstruire.

Je viens de rencontrer cela et je n'ai pas vu de cas similaire similaire au mien.

Dans le .csprojfichier de mon projet de test, la confidentialité des références 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 mis <Private>à Truecela a fonctionné.

Il vous suffit d'installer ce package uniquement:

NUnit TestAdapter

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 package.

Téléchargé depuis https://visualstudiogallery.msdn.microsoft.com/0da0f6bd-9bb6-4ae3-87a8-537788622f2d

J'ai eu exactement le même problème.

Cela é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 corriger, utilisez "Outils> Extensions et mises à jour" et recherchez NUnit3 Test Adapter, il a découvert mes tests après cela.

À votre santé

Disons simplement, pour des raisons d'argumentation, que vous devez 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 - Paramètres de test . Définir ceci sur X64 a permis à mon explorateur de tests de trouver mes tests à l'aide de Microsoft.VisualStudio.TestTools.UnitTesting.

Désolé d'avoir ajouté à 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 `` Tout exécuter '' dans l'Explorateur de tests, puis en regardant la fenêtre de sortie de construction dans Visual Studio. Vous devez le regarder activement, car ensuite le message disparaît.

En ce qui concerne le problème, il semble que lors de l'analyse des tests, la DLL est chargée et ses types de tests sont énumérés. Cela entraîne le chargement des références et en cas d'échec pendant ce processus, les tests ne seront pas affichés dans l'explorateur. J'ai eu deux problèmes empêchant le chargement de la DLL de test:

• Il restait encore une redirection de liaison dans le fichier de configuration (redirection vers une version NHiberate inférieure à celle référencée dans le projet de test).
• Une référence d'assemblage en conflit (les références de 2e niveau ne peuvent pas être chargées). AsmSpy est d'ailleurs un excellent outil pour les chasser.

Si vous chargez une solution Visual Studio (VS 2015 Community dans mon cas) à partir d'un partage réseau ou d'un répertoire Mes documents qui fait 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.

Après avoir passé 2 jours ... rien de ce qui précède n'a fonctionné pour moi. La seule "solution" était: Allez dans les propriétés du projet -> onglet Build. Cliquez ensuite sur le bouton Avancé dans le coin inférieur droit du volet. Modifiez «Informations de débogage:» sur «complet» et cliquez sur OK.

Voici les captures d'écran:

Je suis tombé sur le même problème. Et enquêté et constaté que les DLL n'étaient pas compilées et placées dans le bon dossier. dès que j'ai changé ma configuration, ils sont apparus. - les options de construction des projets, quel dossier utiliser? - la configuration de construction de l'entrée du menu de construction, ils doivent être vérifiés.

qui l'a arrangé pour moi.

Pour 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 des tests unitaires.

Assurez-vous que tous vos projets sont exécutés avec la même configuration. Sous Propriétés de votre projet => Déboguer => Plate-forme dans la liste déroulante, choisissez la plate-forme appropriée (pour moi, c'était "N'importe quel processeur") comme déterminé dans 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é ...
• Une fois qu'une reconstruction propre n'a pas résolu le problème pour moi, l'exécution d'une compilation par lots complète l'a résolu.

Eu le même problème; les tests ont soudainement cessé d'être découverts.

L'adaptateur de test Nunit était en quelque sorte désactivé. Cliquer sur activer dans le gestionnaire d'extensions l'a corrigé pour moi.

J'ai eu le même problème jusqu'à ce que je réalise que j'ai fait une erreur de copier / coller et que je suis parti [Test Method]avant le test.