c# - unitaire - visual studio 2017 generate documentation




Pourquoi Visual Studio 2012 ne trouve-t-il pas mes tests? (20)

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 ) installé le paquet NUnit3 NuGet à mon projet de test. J'avais déjà installé l'extension NUnit Test Adapter, et mes tests ne s'affichaient toujours pas.

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

J'ai quelques tests qui utilisent le Microsoft.VisualStudio.TestTools.UnitTesting intégré, mais ne peut pas les faire fonctionner.

J'utilise Visual Studio 2012 ultime.

J'ai une solution de deux projets; On a des tests, en using Microsoft.VisualStudio.TestTools.UnitTesting , [TestClass] avant la classe, [TestMethod] avant les méthodes de test et de 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. L'explorateur de test a le message `Construire votre solution pour découvrir tous les tests disponibles. Cliquez sur "Exécuter tout" pour créer, découvrir et exécuter tous les tests dans votre solution.

Donc la question est: Comment puis-je 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 suis coincé dans la section pour commencer, lorsqu'on lui demande de faites un clic droit et sélectionnez create tests . Il n'y a pas de create tests .

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

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 que c'est sur un disque partagé, mais je ne sais pas encore comment le contourner. (quelque chose sur le réglage de sécurité peut-être).


Aucune des solutions ici 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 ceci en supprimant le fichier solutionname.v12.suo.


Ce sont toutes de bonnes réponses, mais il y a une raison de plus que je connais; Je viens de courir dedans. Dans l'un de mes tests, j'ai reçu un message ReSharper indiquant que j'avais une classe privée inutilisée. C'était un cours que je vais utiliser dans un test à venir. Cela a en fait causé la disparition de tous mes tests.


Cela fonctionne parfois.

Vérifiez que l'architecture du processeur dans 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 les autres messages, assurez-vous que la fenêtre Test Explorer est ouverte. Test -> Windows -> Explorateur de test

Ensuite, la reconstruction du projet avec les tests devrait faire apparaître les tests dans Test Explorer.

Edit: Comme Ourjamie l'a souligné ci-dessous, faire une construction propre peut aussi 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 Construire -> Gestionnaire de configuration. Assurez-vous que la case de construction de votre projet de test a été cochée pour toutes les configurations de solution et plates-formes de solution.


Dans ma récente expérience, tout ce qui précède n'a pas fonctionné. Ma méthode d'essai

public async void ListCaseReplace() { ... }

ne se présentait pas mais compilait bien. Lorsque j'ai supprimé le mot-clé async le test est apparu dans l'Explorateur de test. C'est parce que async void est une méthode 'fire-and-forget'. Rendez la méthode async Task et vous obtiendrez votre test!

De plus, ne pas avoir configuré la configuration du projet Test sur "Build" empêchera également les tests d'apparaître. Configuration Manager> Vérifiez votre test à générer.


De la barre de menu en haut ...

Test -> Exécuter -> Tous les tests

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

En outre 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 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églé le problème pour moi!


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

Le changement à 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 dans la classe de test affectée étaient disponibles dans l'Explorateur de test.


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 unittest cible x64. Lorsque j'ai créé le projet, il ciblait initialement x86.

Après avoir basculé en x64, tous mes tests unitaires ont disparu.

Je devais aller au menu de test -> Configuration de test - Architecture de processeur par défaut -> x64.

Ils ne sont toujours pas apparus.

A fait une construction.

Toujours pas montré.

Enfin fait un nettoyage

Puis ils sont arrivés.

Je trouve que Clean Solution et Clean sont très utiles pour que les solutions jouent à la balle lorsque le réglage a changé. Parfois, je dois aller à l'extrême et supprimer les répertoires obj et bin et faire une reconstruction.


J'ai mis à jour VS 2012 à la dernière mise à jour. c'est-à-dire la mise à jour visuelle de studio 3. Cela a arrangé le problème pour moi.


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 Unit Tests en 2012, et après l'ouverture en 2013, le projet Unit Test ne montrerait aucun test dans l'explorateur de tests. Chaque fois que j'ai essayé d'exécuter ou de déboguer des tests, il a échoué, 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 conforté dans le fait que le projet Unit Tests faisait encore référence à 2012. En regardant la référence du projet, j'ai réalisé qu'il visait le mauvais Microsoft Visual DLL de Studio Unit Test Framework 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 test et maintenant tous les tests sont trouvés et fonctionnent parfaitement.


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 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 trouvé que la meilleure façon de résoudre ce problème est de créer un fichier .proj msbuild et d'ajouter vos projets de tests unitaires qui ont un problème dans ce fichier et d'exécuter les tests en utilisant 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 depuis mstest - sinon le projet de test est bien construit. Vous trouverez également des problèmes de référence indirecte avec cette méthode. Une fois que vous pouvez exécuter le test Unit à partir de la ligne de commande à l'aide de mstest, vous pouvez alors faire une solution propre, reconstruire la solution et votre test devrait être découvert correctement.


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 post de débordement de pile discutant de cette erreur , et la même solution fonctionne pour eux. La question reste de savoir pourquoi cela fonctionne.


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é. Ce qui a fini par être le problème était que la classe n'était pas "incluse dans le projet". Je l'ai seulement trouvé en redémarrant 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 classes que j'avais écrites, ne sont pas inclus. J'espère que cela pourra aider


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.


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

Je venais d'apporter une solution existante sur ma machine (clonée depuis gitHub) et nous ne suivions pas les fichiers .cs générés automatiquement créés par Visual Studio. (Pour chaque fichier de caractéristiques, il y a un fichier .cs avec le même nom)

L'ouverture de la solution sans les fichiers .cs associés me permet en fait de naviguer vers les méthodes liées. Il semble donc que le flux de spécification a été câblé correctement, mais je n'ai pas pu voir les noms de test dans l'Explorateur de test.

Pour ce problème, en excluant simplement les fichiers de caractéristiques du projet et en les ré-incluant, VS forcé à 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 test.


Puisque le projet est sur un lecteur partagé comme l'a indiqué 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 cet article de blog .

Pour permettre à VS.NET de charger des éléments d'un partage réseau, il faut les ajouter (partages) aux emplacements de confiance. Pour ajouter un emplacement à une liste de confiance complète (modifiez-la si nécessaire pour votre environnement):

 caspol -m -ag 1.2 -url file:///H:/* FullTrust

Pour vérifier ou répertorier les emplacements de confiance existants, exécutez:

 caspol -lg

Vérifiez les assemblys référencés pour les assemblys qui peuvent avoir "Copy Local" défini sur "False".

Si votre projet de test crée son propre dossier (bin / Debug par exemple) et que le projet dépend d'un autre assembly et qu'un de ces assemblys dans la liste References est marqué Copy Local = "False", l'assembly ne peut pas charger en raison de dépendances manquantes. vos tests ne seront pas chargés après une construction.


Vérifiez que votre projet de test n'est pas défini sur le signe 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.







unit-testing