Pourquoi visual studio 2012 ne trouve-t-il pas mes tests?
J'ai des tests qui utilisent le Microsoft.VisualStudio.TestTools.UnitTesting intégré, mais je ne peux pas les faire fonctionner.
J'utilise Visual Studio 2012 Ultimate.
J'ai une solution de deux projets; On a des tests, using Microsoft.VisualStudio.TestTools.UnitTesting, [TestClass] avant la classe, [TestMethod] avant les méthodes de test et référence Microsoft.VisualStudio.QualityTools.UnitTestFramework (version 10.0.0.0, version d’exécution v2.0.50727). J'ai essayé dot-net framework 3.5, 4 et 4.5, d'autres donnent une erreur de re-ciblage.
J'ai essayé de construire la solution et le projet. Test Explorer contient le message `Construisez votre solution pour découvrir tous les tests disponibles. Cliquez sur "Tout exécuter" pour créer, découvrir et exécuter tous les tests de votre solution.
La question est donc: comment obtenir Visual Studio pour trouver les tests?
J'ai également essayé de suivre ceci: http://msdn.Microsoft.com/en-US/library/ms379625%28v=VS.80%29.aspx mais sans succès: je reste bloqué section de démarrage, lorsque vous êtes invité à cliquer avec le bouton droit de la souris et sélectionnez create tests. Il n'y a pas create tests.
J'ai ce test (il compile, mais n'apparaît pas dans le test Explorer):
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace tests {
[TestClass]
public class SimpleTest {
[TestMethod]
public void Test() {
Assert.AreEqual("a","a", "same");
}
}
}
J'ai maintenant découvert (voir réponse supprimée ci-dessous) que c'est parce qu'il se trouve sur un lecteur partagé, mais je ne sais pas encore comment le contourner. (quelque chose à propos des paramètres de sécurité peut-être).
Le problème était que le lanceur de tests est configuré pour ne pas exécuter de tests à partir d'un lecteur distant. Lorsque j'ai copié le projet sur un lecteur local, cela a bien fonctionné, mais j'en avais besoin sur un lecteur partagé (je ne me souviens plus pourquoi).
J'ai lu qu'il pouvait être configuré pour fonctionner à partir d'un lecteur partagé, mais je ne l'avais jamais fait car au moment où j'ai découvert la solution, j'avais opté pour MonoDevelop sur Debian.
J'ai eu les mêmes symptômes, mais dans des circonstances différentes.
J'ai dû ajouter une étape supplémentaire à la solution de Peter Lamberg: nettoyez votre solution/projet.
Mon projet unittest cible x64. Lorsque j'ai créé le projet, il visait initialement x86.
Après être passé en x64, tous mes tests unitaires ont disparu.
Je devais aller dans le menu Test -> Test Setting - Architecture de processeur par défaut -> x64.
Ils ne sont toujours pas venus.
Fait une construction.
Ne s'est toujours pas présenté.
Enfin fait un nettoyage
Puis ils se sont présentés.
Je trouve que Clean Solution et Clean sont très utiles pour trouver la solution pour jouer au ballon lorsque les réglages ont changé. Parfois, je dois aller à l'extrême et supprimer les répertoires obj et bin et procéder à une reconstruction.
Veuillez ajouter le mot clé public à la définition de votre classe. Votre classe de test n'est actuellement pas visible en dehors de son propre assemblage.
namespace tests {
[TestClass]
public class SimpleTest {
[TestMethod]
public void Test() {
Assert.AreEqual("a","a", "same");
}
}
}
Cela fonctionne parfois.
Vérifiez que l'architecture du processeur dans le menu Test correspond à celle utilisée pour générer la solution.
Test -> Paramètres de test -> Architecture de processeur par défaut -> x86/x64
Comme mentionné dans d'autres publications, assurez-vous que la fenêtre Test Explorer est ouverte. Test -> Windows -> Test Explorer
Ensuite, la reconstruction du projet avec les tests doit faire apparaître les tests dans Test Explorer.
Edit: Comme Ourjamie l’a souligné ci-dessous, une construction propre peut également aider. En plus de cela, voici une dernière chose que j'ai rencontrée:
La case à cocher "Construire" n'a pas été cochée dans Configuration Manager pour un nouveau projet de test que j'avais créé avec la solution.
Allez à Construire -> Gestionnaire de configuration. Assurez-vous que la case de construction du projet de test est cochée pour toutes les configurations de solution et les plates-formes de solution.
J'ai Visual Studio 2012 et je ne pouvais pas voir les tests dans Test Explorer,
J'ai donc installé les éléments suivants: NUnit Test Adapter
Cela a résolu le problème pour moi!
Dans ma récente expérience, tout ce qui précède n'a pas fonctionné. Ma méthode de test
public async void ListCaseReplace() { ... }
ne se présentait pas mais compilait bien. Lorsque j'ai supprimé le mot clé async, le test s'est affiché dans l'Explorateur de tests. Ceci est une cause async void est une méthode "feu et oublie". Faites la méthode async Task et vous obtiendrez votre test!
En outre, le fait de ne pas définir la configuration du projet de test sur "Construire" empêchera également l'affichage des tests. Gestionnaire de configuration> Vérifiez votre test pour construire.
Comme le projet est sur un disque partagé comme l'affiche l'affiche originale. VS.NET doit approuver l’emplacement réseau avant de charger et d’exécuter vos assemblages de test. avoir une lecture de ce blog .
Pour permettre à VS.NET de charger des éléments d’un partage réseau, il est nécessaire de les ajouter (partages) à des emplacements approuvés. Pour ajouter un emplacement à une exécution complète de la liste de confiance (évidemment, modifiez-le si nécessaire pour votre environnement):
caspol -m -ag 1.2 -url file:///H:/* FullTrust
Pour vérifier ou répertorier les emplacements approuvés existants, exécutez:
caspol -lg
Un problème que j'ai constaté est que les tests ne sont pas trouvés dans l'explorateur de tests (rien ne s'affiche) si la solution est exécutée à partir d'un lecteur réseau/d'un emplacement réseau/d'un lecteur partagé.
Vous pouvez résoudre ce problème en ajoutant une variable d'environnement.
COMPLUS_LoadFromRemoteSources et définissez sa valeur sur 1
Liste de contrôle rapide pour résoudre certains problèmes de test courants. Sois sûr que:
- La classe de test et les méthodes de test sont
public - La classe de test a l'attribut
[TestClass] - Les méthodes de test ont l'attribut
[TestMethod]
Si cela ne résout pas le problème, essayez de nettoyer, de reconstruire la solution et de redémarrer Visual Studio.
Je recevais l'erreur: "Failed to initialize client proxy: could not connect to vstest.discoveryengine.exe."
Essayez d'exécuter Visual Studio en tant qu'administrateur. Cela a fonctionné pour moi.
Il y a un autre poste de Stack Overflow traitant de cette erreur , et la même solution fonctionne pour eux. La question reste de savoir pourquoi cela fonctionne.
J'ai eu le même problème .. Dans mon cas, il a été causé par un propriété privéeTestContext.
Le changer pour ce qui suit a aidé:
public TestContext TestContext
{
get;
set;
}
Après avoir nettoyé et construit la solution (comme décrit dans la réponse de @Ourjamie), les méthodes de test de la classe de test concernée étaient disponibles dans Test Explorer.
J'ai rencontré le même problème en essayant d'ouvrir la solution sur un partage réseau. Aucun test unitaire ne serait détecté par Test Explorer dans ce cas. La solution s'avère être:
Panneau de configuration -> Options Internet -> Onglet "Sécurité" -> Cliquez sur "Intranet" et ajoutez l'adresse IP du serveur ou le nom d'hôte contenant le partage réseau à la liste "Sites".
Après cela, j'ai recompilé la solution et maintenant les tests sont apparus. Cela devrait être assez similaire à la réponse de @BigT.
J'ai parfois les mêmes symptômes.
Ce que j'ai fait c'est:
1. Fermez la fenêtre Test Explorer
2. Nettoyé la solution
3. Reconstruire la solution
4. Nouvelle fenêtre de Test Explorer à partir de Test -> Windows -> Test Explorer.
Et j'ai eu mon test dans la fenêtre Test Explorer.
Dans mon cas, c'était autre chose. J'avais installé un paquet, puis désinstallé et réinstallé une version antérieure. Cela laissait un résiduel configuration/runtime/asssemblyBinding/dependencyIdentity redirigeant dans mon app.config. Je devais le corriger. Je l'ai compris en regardant la fenêtre Output et en sélectionnant "Tests" dans le menu déroulant. Le message d'erreur était là. C'était une douleur ... J'espère que cela aide quelqu'un d'autre.
J'éprouvais ce problème à plusieurs reprises lorsque j'essayais de générer la solution sur un autre PC.
J'utilise NUnit et Specflow également. Par défaut, mon projet de test cible X86, mais je dois le changer en X64. Les étapes sont 1. Menu Test -> Paramètre de test - Architecture de processeur par défaut -> x64. 2. Nettoyer la construction 3. Construire 4. Si les tests ne sont toujours pas apparus. 5. Allez dans Outils Extensions et mises à jour, puis installez les bibliothèques NUnit et Specflow 6. Nettoyez la construction 7. Construisez
Ensuite, habituellement, le test apparaît dans Test Editor.
De la barre de menu en haut ...
Test -> Exécuter -> Tous les tests
Vous pouvez également afficher tous les tests à partir de Test Explorer (Test -> Windows -> Test Explorer)
En outre, avec VS 2012, si vous manquez quelque chose, essayez de le rechercher à l'aide de la barre de lancement rapide en haut à droite (Ctrl + Q) "Test"
J'espère que cela t'aides.
C'est plus pour aider les gens qui se retrouvent ici que pour répondre à la question du PO:
Essayer de fermer et de rouvrir visual studio, a fait le tour pour moi.
J'espère que ça aide quelqu'un.
J'ai trouvé que le meilleur moyen de résoudre ce problème est de créer un fichier mspro .proj et d'ajouter vos projets de tests unitaires à un problème dans ce fichier, puis d'exécuter les tests à l'aide de la version en ligne de commande de mstest. J'ai trouvé un petit problème de configuration dans mon app.config qui n'apparaissait que lors de l'exécution des tests à partir de mstest. Sinon, le projet de test a été construit correctement. Vous trouverez également tous les problèmes de référence indirects avec cette méthode. Une fois que vous pouvez exécuter le test unitaire à partir de la ligne de commande à l'aide de mstest, vous pouvez alors créer une solution propre, reconstruire la solution et votre test doit être détecté correctement.
Je sais que c'est une question plus ancienne, mais avec Visual Studio 2015, je rencontrais des problèmes pour lesquels ma classe de test nouvellement créée n'était pas reconnue. J'ai tout essayé. Ce qui a fini par être le problème, c'est que la classe n'était pas "incluse dans le projet". Je ne l'ai trouvé qu'au redémarrage de Visual Studio et en remarquant que ma classe de test n'y était pas. Lors de l'affichage des fichiers cachés, je l'ai vu, ainsi que d'autres classes que j'avais écrites, n'étaient pas incluses. J'espère que ça t'as aidé
Vérifiez les assemblages référencés pour tous les assemblages pour lesquels "Copy Local" peut être défini sur "False".
Si votre projet test génère dans son propre dossier (bin/Debug par exemple) et qu'il dépend d'un autre assembly et que l'un de ces assemblys dans la liste des références est marqué Copy Local = "False", l'assembly ne peut pas se charger car des dépendances manquantes et vos tests ne se chargeront pas après une construction.
J'ai eu le même problème, mais un peu différent.
J'utilisais Visual Studio 2012. Pour une raison quelconque, seuls les tests du fichier généré initialement étaient en cours d'exécution. Mais les tests dans un autre fichier ne fonctionnaient pas. J'ai essayé différentes solutions publiées ici, mais cela n'a pas fonctionné.
Enfin, j'ai découvert que j'avais une méthode privée dans la classe de test, qui était la première méthode de la classe. Je viens de déplacer la méthode privée après une méthode de test; Alors maintenant, une méthode avec l'attribut [TestMethod] est la méthode première à l'intérieur de la classe. Étrange, mais maintenant ça marche.
J'espère que cela aidera quelqu'un un jour.
Il semble que NUnit Framework 2.6.4 ne fonctionne pas bien avec NUnit Test Adapter. Sur le site Web, il est mentionné que l'adaptateur de test fonctionnera uniquement avec NUnit Framework 2.6.3.
C'était mon problème: 1. J'avais téléchargé NUnit et NUnit Test Adapter séparément via Nuget dans le VS2012. Quelque part, NUnit a été mis à jour à la version 2.6.4. Soudainement, je n'ai pas vu mes cas de test répertoriés.
Réparer:
Désinstallez Nuget and Nuget Test adapter
une. Sélectionnez Outils> Nuget> Gestionnaire de pépites> Gérer les pépites pour la solution.
b. Lister les paquets installés
c. Cliquez sur gérer
ré. Décochez vos projets
Installer l'adaptateur de test NUnit, y compris NUnit 2.6.3 Framework
Solution de nettoyage/reconstruction
Ouvrir Test> Explorateur de tests> Tout exécuter
Je vois tous les cas de test
J'espère que cela t'aides
Les tests n'aiment pas les méthodes asynchrones. Par exemple:
[TestMethod]
public async void TestMethod1()
{
TestLib oLib = new TestLib();
var bTest = await oLib.Authenticate();
}
Après avoir fait ceci:
[TestMethod]
public void TestAuth()
{
TestMethod1();
}
public async void TestMethod1()
{
TestLib oLib = new TestLib();
var bTest = await oLib.Authenticate();
}
Il a vu le test.
Je rencontre le même problème en essayant d'ouvrir la solution sur un partage réseau dans VS2013 Ultimate.
J'ai corrigé le problème en allumant
Panneau de configuration -> Options Internet -> Onglet "Sécurité" -> Cliquez sur "Intranet local", cliquez sur les sites et assurez-vous que "Détecter automatiquement le réseau intranet" est coché.
J'ai rencontré ce problème lors de la mise à niveau de ma solution de Microsoft Visual Studio 2012 Express pour Web vers Microsoft Visual Studio 2013.
J'avais créé un projet de tests unitaires en 2012 et, après son ouverture en 2013, le projet de tests unitaires ne montrait aucun test dans l'explorateur de tests. À chaque fois que j'essayais d'exécuter ou de déboguer des tests, cela échouait en disant ce qui suit dans la fenêtre de sortie:
Failed to initialize client proxy:
could not connect to vstest.discoveryengine.x86.exe
J'ai également remarqué que lors du débogage des tests, il lançait une instance de Visual Studio 2012. Cela m'a permis de comprendre que le projet de tests unitaires faisait toujours référence à 2012. En regardant la référence du projet de test, j'ai réalisé qu'elle visait le mauvais Microsoft Visual. Studio Unit Test Framework DLL pour cette version de Visual Studio:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
J'ai changé le numéro de version de 11.0 à 12.0:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
J'ai tout reconstruit et cela a résolu le problème - tous les tests ont été trouvés dans l'Explorateur de tests et maintenant tous les tests sont trouvés et fonctionnent parfaitement.
Ce sont toutes d'excellentes réponses, mais il y a une raison de plus que je connais; Je viens de le rencontrer. Lors de l'un de mes tests, un message ReSharper indiquant que j'avais une classe privée non utilisée était affiché. C'était un cours que je vais utiliser lors d'un prochain test. Ceci a en fait causé la disparition de tous de mes tests.
Vérifiez que votre projet de test est non défini sur signe de retard uniquement dans les propriétés de votre projet -> Signature. Si c'est le cas, désélectionnez-le et effectuez une reconstruction propre.
Aucune des solutions ici ne m'a aidé. Les tests ne seraient pas découverts pour une solution alors qu'une autre solution référençant les mêmes projets fonctionnait bien. J'ai finalement résolu ce problème en supprimant le fichier solutionname.v12.suo.
J'ai mis à jour VS 2012 avec la dernière mise à jour. C'est-à-dire la mise à jour 3 de Visual Studio. Le problème a été résolu pour moi.
Pour moi, la solution était un peu moins compliquée.
Je venais tout juste d'apporter une solution existante sur ma machine (clonée à partir de gitHub) et nous ne suivons pas les fichiers .cs générés automatiquement que Visual Studio a créés. (Pour chaque fichier de caractéristiques, il existe un fichier .cs portant le même nom)
Ouvrir la solution sans avoir les fichiers .cs associés me permet en fait de naviguer vers les méthodes liées. Il semblait donc que specflow était correctement câblé, mais je n’étais pas en mesure d’afficher les noms des tests dans Test Explorer.
Pour ce problème, excluant simplement les fichiers de fonctionnalités du projet, puis les ré-inclure, VS oblige à régénérer ces fichiers codebehind générés automatiquement.
Après cela, j'ai pu voir les tests dans l'explorateur de tests.
Ajouter ma réponse car c’est le meilleur résultat sur Google pour cela.
J'utilise Visual Studio 2015 et (sans le savoir - je viens de lancer Install-Package NUnit]) a installé le package NUnit3 NuGet sur mon projet de test. J'avais déjà l'extension NUnit Test Adapter installée et mes tests ne se montraient toujours pas.
L'installation de l'adaptateur de test NUnit3 via Outils> Extensions et mises à jour a résolu ce problème.
Après googler "Visual Studio ne peut pas voir les tests", cela m’a amené ici, alors j’ai pensé partager mon problème. Je pouvais construire ma solution et les tests existaient, mais je ne pouvais pas les voir ! Il s’agit en fait de c’est un caprice de l’IDE qui a posé le problème. Voir l'image ci-dessous pour une explication et une solution:
Voici un autre élément à ajouter à la liste en fonction de l'erreur utilisateur/de la stupidité .... J'ai essayé diverses réponses à cette question, puis je me suis rendu compte que mon projet de test n'avait pas été coché dans le Gestionnaire de configuration (menu Construire, Gestionnaire de configuration). construit>. <
En publiant ceci dans l’espoir, cela évitera à quelqu'un de perdre une heure ou deux comme je viens de le faire!
Un autre problème qui peut empêcher la découverte de tests, généralement avec un message dans la fenêtre de sortie de tests, tel que:
Impossible de configurer les paramètres du plug-in runsettings 'Configuration d'exécution VSTest' car il a généré l'exception suivante: 'Une erreur s'est produite lors de l'analyse de EntityName. Ligne 1, position 8. ' Veuillez contacter l'auteur du plugin.
Cela peut être dû au fait que des caractères de votre chemin ou des noms de fichiers nécessitant un échappement doivent être analysés au format xml. Plus précisément, les caractères &, tels que < et >, ne sont pas autorisés dans les noms de répertoire ou de fichier. Cela provoque la chute de la découverte de test sans identifier les tests, mais je peux toujours exécuter les tests à la main en utilisant Resharper en cliquant dans la marge.
Je rencontrais le même problème dans Visual Studio 2013 Update 4 sur Windows 7 SP1 x64 à l'aide d'un projet de test ciblant la configuration de la plate-forme "Tout processeur".
Le problème était que le projet de test s'appelait en fait "Tests" et disparaîtrait la deuxième fois que le projet était (re) construit.
Après avoir renommé le projet en "MyProject.Tests" par exemple, les tests ne disparaissent plus.
J'ai essayé tout ce qui est mentionné ci-dessus et mon Visual Studio 2012 ne s'affiche toujours pas aux tests. En fin de compte, je suis allé dans une classe de test et j'ai découvert qu'il y avait un RootNamespace.FolderName et j'ai supprimé le .FolderName pour mettre la classe dans l'espace de noms racine et tous les tests sont revenus!
Je ne comprends pas pourquoi cela fonctionnait bien avec l’espace de noms original jusqu’à l’autre jour.
Visual Studio Professional 2012, mise à jour 4 ici. Avoir des définitions de fonction Interop (DllImport/extern) dans le même projet que les classes de test confondait Test Explorer. Déplacer Interop dans un projet distinct a résolu le problème.
Visual Studio 2015 (v.14 .....) - même problème ici
Cause: différentes versions de NUnit et NUnit Test Adapter Dans mon cas, j'avais les dernières versions de NUnit (3.5) et de NUnit Test Adapter, mais l'adaptateur de test n'était pas la bonne. Pour NUnit 3 et supérieur, il faut utiliser un NUnit3TestAdapter
Solution: Désinstaller l'adaptateur de test NUnint "défectueux" et installer UNit3TestAdapter v.3.5.0 (le dernier en date est 3.6.0 mais ne l'a pas utilisé pour le conserver identique à NUnit)
Après la reconstruction de la solution, des tests sont apparus :)
La chose la plus simple à faire est de faire glisser ces fichiers de l’explorateur de fichiers vers le projet test. Construisez à nouveau le projet et vous êtes prêt à partir!
OR
Ouvrez le fichier .csproj de votre projet test dans un éditeur de texte et incluez manuellement le nom du fichier à compiler. Recherchez la balise Compile dans le fichier et ajoutez le fichier que vous souhaitez exécuter.
<ItemGroup>
<Compile Include="TestSettings.cs" />
<Compile Include="TestLibrary.cs" />
<Compile Include="UnitTest1.cs" />
</ItemGroup>
Ajoutez la balise Compile pour votre fichier et enregistrez-le. Maintenant, lancez les tests. Votre fichier avec test unitaire sera détecté et exécuté.
Puisqu'aucune de ces réponses ne traite de la cause que j'ai rencontrée, pour ce problème, j'ajouterai ma réponse ici aussi.
Dans mon cas, c'était un problème de code de copie/collage. Nous avions un TestProjectA dans lequel il existe des types de tests spécifiques que nous souhaitons utiliser dans son propre projet de test - TestProjectB. Le problème était maintenant que, bien que les tests dans TestProjectA continuent à s'afficher correctement, les tests dans le nouveau TestProjectB n'apparaissent pas dans VS Test Explorer - à moins que vous ne construisiez spécifiquement TestProjectB ou manuellement, faites un clic droit sur un test et exécutez-le.
La cause en était que lors du copier-coller du code, certains espaces de noms n'étaient pas mis à jour:
- Il y a une
TestMethodA()dansTestClassAdans l'espace de nomsTestProjectA.ModuleAavec le chemin de fichier\TestProjectA\TestClassA.cs - Ainsi qu'une
TestMethodA()dansTestClassBdans un espace de nomsTestProjectA.ModuleAavec le chemin de fichier\TestProjectB\TestClassB.cs
Donc, Visual Studio imprime un message dans la fenêtre de sortie indiquant que le TestId de ces deux-là est identique et continue d'afficher TestProjectA et non pas TestProjectB dans Test Explorer en raison du conflit entre TestId et les deux projets. Corriger l’espace de noms en TestProjectB.ModuleB pour \TestProjectB\TestClassB.cs a résolu le problème.
Ce problème semble avoir tellement de solutions différentes que je peux aussi ajouter la mienne:
Fermer Visual Studio
Renommez C:\Users\nom d'utilisateur\AppData\Local\Microsoft\VisualStudio\12.0\ComponentModelCache en ComponentModelCache.old
Exécutez Visual Studio et le cache du composant sera reconstruit.
Celui-ci vient de me mordre. J'ai ajouté un test à mon projet, mais je ne pouvais pas le faire apparaître dans Test Explorer. Mes anciens tests sont tous apparus. Finalement, j'ai réalisé que je ne visionnais qu'une liste de lecture spécifique et que je n'avais pas ajouté le nouveau test à la liste de lecture. Si vous utilisez des listes de lecture, sélectionnez "Tous les tests" et voyez si VS trouve vos tests et les affiche dans Test Explorer. Ensuite, vous pouvez aussi les ajouter à la liste de lecture souhaitée.
Nous utilisions xunit et la solution fonctionnait pour moi et l'équipe supprimait le dossier% TEMP%\VisualStudioTestExplorerExtensions.
Lire ce fil.
Pourquoi Run Runner de Visual Studio 2015/2017 ne découvre-t-il pas mes tests xUnit v2
J'ai lu toutes les réponses existantes et constaté que mes tests (xUnit) n'étaient pas découverts car j'avais supprimé les références "non utilisées" et plus précisément, xunit.execution.desktop. Réinstaller le paquet xUnit a résolu le problème dans mon cas.
Dans mon cas, j'avais 3 projets de test, créés avec Visual Studio 2017 (mais je pense que cela n'a pas d'importance), et seulement deux d'entre eux ont été découverts par l'Explorateur de tests. J'ai réalisé que le troisième projet avait une version différente de la Microsoft.VisualStudio.QualityTools.UnitTestFramework dll. Je l'ai mis à jour dans le gestionnaire NuGet et les tests sont apparus.
J'ai rencontré le même problème dans VS2013 Ultimate. Mon problème était que je créais un service Windows et que j'avais oublié de le désinstaller. Donc, le service était en cours d'exécution et VS ne pouvait pas accéder à l'une des DLL, ce qui a empêché toute la suite de tests de charger.
Un problème que j'ai rencontré à plusieurs reprises ne tourne pas (explicitement) dans Visual Studio en tant qu'administrateur sur Windows 8+. J'ai essayé plusieurs des suggestions énumérées, mais les tests unitaires ne sont pas apparus tant que je n'ai pas exécuté VS 2013 en tant qu'administrateur (même si mon raccourci est configuré pour ouvrir VS de cette façon, soit en ouvrant le fichier de solution, soit en cliquant parfois sur le raccourci indiqué. pas vraiment ouvert en tant qu'administrateur).
J'ai copié-collé la déclaration de la méthode, qui incluait un paramètre de chaîne d'entrée. J'ai oublié de supprimer le paramètre d'entrée.
public void ExtractValueFromLineTest(string input) {}//test not discovered because of the string input param