Pourquoi Visual Studio 2012 ne trouve pas mes tests?


221

J'ai quelques tests qui utilisent le intégré Microsoft.VisualStudio.TestTools.UnitTesting, 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 que les méthodes d'essai et de référence Microsoft.VisualStudio.QualityTools.UnitTestFramework(version 10.0.0.0, version d' exécution V2.0.50727). J'ai essayé le framework dot-net 3.5, 4 et 4.5, d'autres donnent une erreur de reciblage.

J'ai essayé de construire la solution et le projet. L'Explorateur de tests affiche 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?


Ont également essayé de suivre ceci: http://msdn.microsoft.com/en-US/library/ms379625%28v=VS.80%29.aspx mais sans succès: je suis coincé dans la section de démarrage, lorsqu'on lui a demandé de faites un clic droit et sélectionnez create tests. Il n'y en a pas create tests.


J'ai ce test (il compile, mais n'apparaît pas dans l'explorateur de tests):

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 la 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 sur le paramètre de sécurité peut-être).


Quelle version VS 2012? Vous pouvez télécharger un exécuteur de test comme TestDriven.Net ou il y en a un dans Resharper.
Brett Allred

J'utilise Visual Studio 2012 Ultimate.
ctrl-alt-delor

Veuillez partager la version du framework et la version de la bibliothèque UnitTesting que vous avez ajoutées comme référence
Adil

5
Dans mon cas, la suppression du fichier app.config a corrigé l'explorateur de tests unitaires
Chris Richner

4
Essayez de rechercher des erreurs dans la catégorie «Test» dans la fenêtre de sortie. Je crée des tests fonctionnels à partir de la version de génération et lorsque j'essaie de déboguer à l'aide de la version de débogage (dont les DLL sont situées dans une structure de dossiers différente), je ne reçois aucune erreur de génération, mais je dois regarder sous les tests dans le menu déroulant. Une fois que je les ai résolus, les tests commencent à apparaître dans l'explorateur de tests
gDexter42

Réponses:


227

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 - Nettoyer votre solution / projet.

Mon projet le plus complet cible x64. Lorsque j'ai créé le projet, il ciblait initialement x86.

Après être passé à x64, tous mes tests unitaires ont disparu.

Je devais aller dans le menu Test -> Paramètres de test - Architecture du processeur par défaut -> x64.

Ils ne se sont toujours pas présentés.

A fait une construction.

Toujours pas apparu.

Enfin fait un nettoyage

Puis ils se sont présentés.

Je trouve Clean Solution et Clean très utiles pour obtenir les solutions pour jouer au ballon lorsque le réglage a changé. Parfois , je dois aller à l'extrême et supprimer les objet binrépertoires et faire une reconstruction.


Bien que faire un nettoyage aide parfois, ce n'est pas le problème. J'ai un problème avec des projets sur des lecteurs réseau. Et le fait que la construction aide toujours n'est qu'un symptôme d'un outil de construction de buggy.
ctrl-alt-delor

7
Hou la la! La "Clean Solution" semble vraiment fonctionner (par opposition à une simple reconstruction). Je pensais que cela cessait d'être un hack utile dans Visual Studio 6.0!
Dave

"Clean" n'a pas fonctionné pour mon collègue qui avait ce problème. Cela a fonctionné pour elle après avoir supprimé tout le code source de son espace de travail TFS et avoir obtenu la dernière version (avec écrasement). Ensuite, cela a très bien fonctionné!
Michael R

2
C'était tout pour moi. Dans une solution avec un mélange de x86, Any CPU, x64, les tests d'un projet particulier n'étaient pas trouvés. J'ai nettoyé la solution, changé l'architecture par défaut du paramètre de test et reconstruit, puis tout était visible. Cela n'a vraiment aucun sens, car changer l'architecture a découvert des tests compilés sous une architecture CPU différente.
Ben H

2
Dès que j'ai changé de processeur par défaut - tous mes tests l'ont montré. Merci beaucoup pour cela!
Dan But

160

Veuillez ajouter le mot clé public à votre définition de classe. Votre classe de test n'est actuellement pas visible en dehors de son propre assembly.

namespace tests {
    [TestClass]
    public class SimpleTest {
        [TestMethod]
        public void Test() {
            Assert.AreEqual("a","a", "same");
        }
    }
}

24
Je l'ai fait pour moi, presque embarrassant, je ne l'ai pas découvert par moi-même :)
landi

5
J'ai aussi eu ce problème, le mien a été causé par le fait d' [TestMethod]être statique à cause d'un copier-coller d'un autre code.
Seph

2
@Seph: Mon [TestMethod]s était statique parce que c'est ce que UserTest1.csle nouveau projet de test avait! A également résolu mon problème.
Andre Luus

4
Ne mettez pas non plus staticdevant votre méthode. Je ne sais pas pourquoi je fais ça par habitude si souvent.
levininja

1
Cela l'a fait pour moi, intéressant de voir comment vous pouvez perdre autant de temps sur quelque chose qui aurait dû être si évident. Merci pour la réponse Joe King
Thulani Chivandikwa

58

Cela fonctionne parfois.

Vérifiez que l'architecture du processeur sous le menu Test correspond à celle que vous utilisez pour créer la solution.

Test -> Paramètres de test -> Architecture de processeur par défaut -> x86 / x64

Comme mentionné dans d'autres articles, assurez-vous que la fenêtre Test Explorer est ouverte. Test -> Windows -> Explorateur de tests

Ensuite, la reconstruction du projet avec les tests devrait faire apparaître les tests dans l'Explorateur de tests.

Edit: Comme Ourjamie l'a souligné ci-dessous, faire une construction propre peut également aider. En plus de cela, voici une autre chose que j'ai rencontrée:

La case à cocher "Build" a été décochée dans Configuration Manager pour un nouveau projet de test que j'avais créé sous la solution.

Allez dans Build -> Configuration Manager. Assurez-vous que la case de construction de votre projet de test est cochée pour toutes les configurations de solution et plates-formes de solution.


Oui, cela peut être d'autres raisons pour lesquelles cela ne fonctionnera pas, mais voir la réponse cochée ci-dessous pour savoir pourquoi cela n'a pas fonctionné pour moi. (les dossiers partagés sont désactivés par défaut), si vous pouvez nous dire comment changer cela, je vais vous donner quelques points.
ctrl-alt-delor

Il n'y a pas de processeur tel qu'un x64, mais je pense que Microsoft utilise ce terme pour le x86-64 / amd64 / x86e. Il n'y a pas non plus de x86, juste la famille x86. Le x représente l'inconnu, donc les membres de la famille x64 seraient 164, 264, 364… OU était le x86 un processeur 86 bits.
ctrl-alt-delor

merci pour votre réponse, cela m'aide (je suis passé des versions x86 aux versions x64)
enguerran

Même dans VS 2015, la fenêtre Test Explorer était ouverte. Heureux de pouvoir également exécuter des tests à partir de la ligne de commande.
Bryan

32

J'ai Visual Studio 2012 et je ne pouvais pas voir les tests dans Test Explorer,

J'ai donc installé ce qui suit: Adaptateur de test NUnit

Cela a résolu le problème pour moi!


1
Également disponible via NuGetInstall-Package NUnitTestAdapter
Darren Hale

Merci @DarrenHale. Lors de la recherche de ce package dans NuGet, j'ai également trouvé un ensemble appelé NUnit TestAdapter comprenant NUnit 2.6.4 Framework .
ray

18

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 asyncmot clé, le test s'est affiché dans l'explorateur de tests. C'est parce que la bacause async voidest une méthode qui consiste à «tirer et oublier». Faites la méthode async Tasket vous obtiendrez votre test!

De plus, le fait de ne pas définir la configuration du projet Test sur "Build" empêchera également les tests de s'afficher. Configuration Manager> Vérifiez votre test à construire.


2
Il m'a fallu un bon moment pour comprendre cela. J'ai refactorisé quelques méthodes pour qu'elles soient asynchrones et j'ai juste ajouté le mot-clé aux tests. Ce n'est que lorsque j'ai codé un nouveau test unitaire avec cela que j'ai remarqué que les autres tests manquaient également. J'ai trouvé cette réponse qui explique pourquoi cela se produit.
julealgon

12

Étant donné que le projet est sur un disque partagé comme l'a indiqué l'affiche originale. VS.NET doit approuver l'emplacement réseau avant de charger et d'exécuter vos assemblys de test. Lisez ce billet de blog .

Pour permettre à VS.NET de charger des éléments d'un partage réseau, vous devez les ajouter (partages) à des emplacements approuvés. Pour ajouter un emplacement à une exécution de liste de confiance complète (modifiez évidemment comme requis 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

Cette réponse n'est pas vérifiée par le questionneur, car je n'ai plus d'intérêt pour la réponse. Si cela fonctionne pour vous (ou non), ajoutez un commentaire ci-dessous.
ctrl-alt-delor

6
@richard Donc, vous acceptez une réponse que vous n'avez pas vérifiée et votez contre d'autres réponses qui décrivent des solutions pour différentes causes de votre problème? .... C'est bizarre!
Stephan Bauer

1
Cela s'est avéré être le problème pour moi, mais pas la solution. J'ai tout déplacé localement et tous les tests ont été trouvés! Merci!
Travis Swientek du

1
CasPol.exepeut être trouvé sous %windir%\Microsoft.NET\Framework[64]\[version]. Vérifiez que vous définissez la stratégie pour l'architecture appropriée. Source: msdn.microsoft.com/en-us/library/cb6t8dtz%28v=vs.100%29.aspx
EpicVoyage

C'était aussi le problème pour moi. Si ennuyeux que VS ne les a pas ramassés mais n'a donné aucune indication quant à la cause!
kaybee99

10

Un problème que j'ai trouvé est que les tests ne sont pas trouvés dans l'explorateur de tests (rien ne s'affiche) si la solution s'exécute sur un lecteur réseau / emplacement réseau / lecteur partagé

Vous pouvez résoudre ce problème en ajoutant une variable d'environnement.

COMPLUS_LoadFromRemoteSources et définissez sa valeur sur 1


6

J'ai eu le même problème .. Dans mon cas, il a été causé par une propriété privée TestContext .

La modification de 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 affectée étaient disponibles dans l'Explorateur de tests.


OK mêmes symptômes, donc supprimera le vote négatif, si vous précisez ce que vous avez changé (de quoi).
ctrl-alt-delor

1
J'avais exactement la même chose, j'ai suivi le fil complet, puis je suis venu sur celui-ci et je suis venu à l'idée de le mettre en public, bingo: mes nouveaux tests sont apparus. Je comprends les commentaires précédents mais ... puisque celui-ci nous apporte de Google ... c'est le fil à lire lorsque les tests n'apparaissent pas.
edelwater

1
C'était la cause de mon problème. J'avais un champ pour l'interface de dépendance en tant que champ privé. Tu es un sauveur!
Alex

6

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 avoir fait cela, j'ai recompilé la solution et maintenant des tests sont apparus. Cela devrait être assez similaire à la réponse de @BigT.


6

Liste de contrôle rapide pour résoudre certains problèmes de test courants. Sois sûr que:

  1. La classe de test et les méthodes de test sont public
  2. La classe de test a [TestClass] attribut
  3. Les méthodes de test ont un [TestMethod]attribut

Si cela ne vous aide pas, essayez de nettoyer, de reconstruire la solution et de redémarrer Visual Studio.


Cela résoudra les problèmes de la plupart des visiteurs de cette question et résume la plupart des réponses, mais ne couvre pas le problème de la question.
ctrl-alt-delor

1
Je vous remercie. UTA001: TestClass attribute defined on non-public class
Jarek Przygódzki

6

J'obtenais 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 existe un autre article Stack Overflow traitant de cette erreur , et la même solution fonctionne pour eux. Reste à savoir pourquoi cela fonctionne.


3
A aussi fonctionné pour moi! Je pense que c'est une question distincte.
Justin Morgan

2
Hé, ça marche mec. Merci beaucoup .. Une solution pour le faire fonctionner sans exécuter en tant qu'administrateur?
Sriram Sakthivel

2
Désolé, je ne pense pas que l'exécution en tant qu'administrateur soit une bonne solution. Sauf preuve que c'est le seul moyen.
ctrl-alt-delor

L'exécution en tant qu'administrateur n'est généralement pas un gros problème. Mais l'un des problèmes est que vous ne pouvez pas envoyer Workitem à Outlook.
Edward Olamisan

Modifié votre réponse pour créer un lien vers une publication SO connexe, j'espère que cela ne vous dérange pas. Je suis d'accord avec Sriram et Richard cependant. Bien que cela fonctionne, c'est une solution de contournement, pas une solution. Pourquoi cela fonctionne même du tout ne semble pas clair.
Steven Jeuris

4

J'ai parfois les mêmes symptômes.

Ce que j'ai fait:
1. Fermez la fenêtre de l'Explorateur de tests
2. Nettoyez la solution
3. Reconstruisez la solution
4. Relancez la fenêtre de l'Explorateur de tests à partir de Test -> Windows -> Explorateur de tests.

Et j'ai obtenu mon test dans la fenêtre Test Explorer.


Je ne pense pas que ce soit le même problème.
ctrl-alt-delor

3
Je pense que c'EST le même problème, il est tout simplement causé par autre chose.
Stephan Bauer

2

De la barre de menu en haut ...

Test -> Exécuter -> Tous les tests

Vous pouvez également afficher tous les tests de Test Explorer (Test -> Windows -> Test Explorer)

De plus avec VS 2012, si vous manquez quelque chose, essayez de le rechercher en utilisant la barre de lancement rapide en haut à droite (Ctrl + Q) "Test"

J'espère que cela t'aides.


J'ai essayé cela, les deux fonctionnent avec nunit. Mais cette fois, j'essaie d'exécuter les tests de quelqu'un d'autre écrits en utilisant Microsoft.VisualStudio.TestTools.UnitTesting, une idée de quoi d'autre je fais mal?
ctrl-alt-delor

Cela ne fait aucune différence ... Parfois, il arrive de ne pas découvrir le test unitaire ... donc si vous ouvrez l'explorateur de test et créez une solution, il fera apparaître le test unitaire dans un certain temps ... Peut-être que vous le savez déjà. ..
Adil

2
Je voulais juste m'assurer que vous utilisiez une version express ou une version qui n'incluait pas d'outils de test. Avez-vous essayé d'installer un lanceur de test tiers?
Brett Allred

2

J'ai trouvé que la meilleure façon de résoudre ce problème est de créer un fichier msbuild .proj et d'ajouter vos projets de test unitaire que vous rencontrez un problème dans ce fichier et 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'est apparu que lors de l'exécution des tests depuis mstest - sinon le projet de test s'est bien passé. 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 ensuite faire une solution propre, reconstruire la solution et votre test doit être détecté correctement.


dans mon cas, l'app.config a également tué l'apparition du test unitaire. Après avoir supprimé app.config et reconstruit le projet de test, ils étaient enfin de retour!
Chris Richner

2

Dans mon cas, c'était autre chose. J'avais installé un package, puis le désinstaller et réinstaller une version antérieure. Cela a laissé une configuration/runtime/asssemblyBinding/dependencyIdentityredirection résiduelle dans mon app.config. J'ai dû le corriger. Je l'ai compris en regardant la Outputfenêtre et en sélectionnant " Tests" dans le menu déroulant. Le message d'erreur était là. Ce fut une douleur ... J'espère que cela aide quelqu'un d'autre.


2

C'est plus pour aider les gens qui se retrouvent ici que pour répondre à la question du PO:

Essayez de fermer et de rouvrir Visual Studio, a fait l'affaire pour moi.

J'espère que cela aide quelqu'un.


2

Je sais que c'est une question plus ancienne mais avec Visual Studio 2015, j'avais des problèmes où ma classe de test nouvellement créée n'était pas reconnue. J'ai tout essayé. Le problème a finalement été que la classe n'était pas "incluse dans le projet". Je n'ai trouvé cela qu'au redémarrage de Visual Studio et en remarquant que ma classe de test n'était pas là. En montrant des fichiers cachés, je l'ai vu, ainsi que d'autres cours que j'avais écrits, n'étaient pas inclus. J'espère que cela pourra aider


2

J'ai rencontré ce problème plusieurs fois lorsque j'essaie de créer la solution sur un autre PC.

J'utilise également NUnit et Specflow. Par défaut, mon projet de test cible X86, mais je dois le changer en X64. Les étapes sont les suivantes: 1. Menu Test -> Paramètres de test - Architecture de processeur par défaut -> x64. 2. Clean Build 3. Build 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, le test apparaît généralement dans l'éditeur de test.


@srebella C'est bien que vous ayez résolu ce problème. J'ai passé des jours à résoudre ce problème. Veuillez partager votre expérience avec la communauté. Veuillez mettre cette réponse en haut si vous pensez que cela fonctionne. Merci :-)
Shiran Jayawardena

1

J'ai mis à jour VS 2012 vers la dernière mise à jour. ie mise à jour de Visual Studio 3. Cela a résolu le problème pour moi.


1

Pour moi, la solution était un peu moins compliquée.

Je venais 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 d'entités, il existe un fichier .cs du même nom)

L'ouverture de 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 le flux de spécifications était correctement câblé, mais je ne pouvais pas afficher les noms des tests dans l'Explorateur de tests.

Pour ce problème, il suffit d'exclure les fichiers de fonctionnalités du projet, puis de les ré-inclure, ce qui oblige VS à 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.


1

J'ai rencontré ce problème lors de la mise à niveau de ma solution de Microsoft Visual Studio 2012 Express for 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 n'affichait aucun test dans l'explorateur de tests. Chaque fois que j'essayais d'exécuter ou de déboguer des tests, cela échouait, 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é qu'en déboguant les tests, il lançait une instance de Visual Studio 2012. Cela m'a permis de comprendre que le projet Unit Tests faisait toujours référence à 2012. En regardant la référence du projet de test, j'ai réalisé qu'il ciblait le mauvais Microsoft Visual DLL de Framework de test d'unité Studio 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.


1

Vérifiez que votre projet de test n'est pas défini sur Signe différé uniquement dans les propriétés de votre projet -> Signature. Si c'est le cas, désélectionnez-le et effectuez une reconstruction propre.


ou sautez simplement la vérification de signature sur votre machine locale en sn -Vr *,<public key token>tant qu'administrateur dans l'invite de commande du développeur VS
Silas

1

J'ai rencontré 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 activant

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


1

Ce sont toutes d'excellentes réponses, mais il y a une raison de plus à ma connaissance; Je suis juste tombé dessus. Dans l'un de mes tests, j'ai reçu un message ReSharper indiquant que j'avais une classe privée inutilisée. C'est une classe que je vais utiliser lors d'un prochain test. En fait, tous mes tests ont disparu.


1

Vérifiez les assemblys référencés pour tous les assemblys dont "Copy Local" peut être défini sur "False".

Si votre projet de test est construit dans son propre dossier (bin / Debug par exemple) et que le projet dépend d'un autre assembly et que l'un de ces assemblys dans la liste Références est marqué Copy Local = "False", l'assembly ne peut pas se charger en raison de dépendances manquantes et vos tests ne se chargeront pas après une build.


1

Il semble que NUnit Framework 2.6.4 ne fonctionne pas bien avec l'adaptateur de test NUnit. Dans le site Web, il mentionne que l'adaptateur de test ne fonctionnera qu'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. D'une manière ou d'une autre, NUnit a été mis à jour en 2.6.4 Soudain, je n'ai pas vu mes cas de test répertoriés.

Réparer:

  1. Désinstaller Nuget et Nuget Test Adapter

    une. Allez dans Outils> Nuget> Gestionnaire de Nuget Pkg> Gérer Nuget Pkg pour la solution

    b. Liste des packages installés

    c. Cliquez sur gérer

    ré. Décochez vos projets

  2. Installer l'adaptateur de test NUnit, y compris le cadre NUnit 2.6.3

  3. Solution de nettoyage / reconstruction

  4. Ouvrez Test> Explorateur de tests> Tout exécuter

Je vois tous les cas de test

J'espère que cela t'aides


1

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 a bien fonctionné. J'ai finalement résolu ce problème en supprimant le fichier solutionname.v12.suo.


1

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é initial étaient en cours d'exécution. Mais les tests d'un autre fichier n'étaient pas en cours d'exécution. J'ai essayé différentes solutions publiées ici, ça n'a pas marché.

Enfin, j'ai compris que j'avais une méthode privée dans la classe de test qui était la première méthode à l'intérieur de la classe. Je viens de déplacer la méthode privée après une méthode de test; maintenant, une méthode avec [TestMethod]attribut est la première méthode à l'intérieur de la classe. Étrange, mais maintenant ça marche.

J'espère que cela aidera quelqu'un un jour.


1

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 cela:

    [TestMethod]
    public void TestAuth()
    {
        TestMethod1();
    }

    public async void TestMethod1()
    {
        TestLib oLib = new TestLib();
        var bTest = await oLib.Authenticate();

    }

Il a vu le test.


Une meilleure réponse est[Test] public void XamarinExampleTest() { // This workaround is necessary on Xamarin, // which doesn't support async unit test methods. Task.Run(async () => { // Actual test code here. }).GetAwaiter().GetResult(); }
Robert Green MBA

3
"Les tests n'aiment pas les méthodes asynchrones " est faux . «Les tests n'aiment pas les méthodes async void » est vrai , et la solution consiste simplement à déclarer une méthode de test comme tâche async .
Massimiliano Kraus

1

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 courir Install-Package NUnit ) installé le package NUnit3 NuGet sur mon projet de test. J'avais déjà installé l'extension de l'adaptateur de test NUnit et mes tests n'apparaissaient toujours pas.

L'installation de l'adaptateur de test NUnit3 via Outils> Extensions et mises à jour a résolu ce problème pour moi.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.