Tests unitaires non découverts dans Visual Studio 2017


213

Je lutte avec VS 2017 depuis que je l'ai installé. Il semble maintenant que les tests unitaires ne seront exécutés qu'à partir de la ligne de commande "test dotnet".

Mon projet est .NET Core 1.1.1. J'ai le SDK et la mise à jour du framework pour 1.1.1 installés.

J'ai essayé l'exemple sur MSDN ( https://msdn.microsoft.com/en-us/library/ms182532.aspx ) qui échoue également exactement de la même manière.

Tous les packages NuGet pour les tests et le projet principal sont à jour. Et le projet de test et le projet principal sont générés sans erreur. Une fois les tests exécutés avec succès à partir de la ligne de commande.

Quelqu'un a-t-il réussi à exécuter les tests unitaires dans VS 2017, si oui, comment?

Merci, John


Mettre à jour - étendre

Voici un exemple d'un projet de test simple qui ne fonctionne pas sur GitHub . Ceci est un exemple avec xUnit mais j'ai essayé NUnit et Visual Studio intégré dans les tests MS. Quels que soient les tests ou les modifications que j'effectue, je ne parviens pas à faire en sorte que le testeur VS trouve des tests.

Ce que j'ai essayé

  • Suppression des fichiers de cache de test VS DEL %TEMP%\VisualStudioTestExplorerExtensions
  • Redémarrage de VS
  • Explorateur de test de fermeture / ouverture
  • pour xUnit installé Microsoft.DotNet.InternalAbstractions( voir l'article SO )
  • pour NUnit, assurez-vous que l'adaptateur est installé et la même version (3) que le package NUnit
  • test -> test settings -> default processor architecture est défini sur x86

La question
Quelqu'un peut-il s'il vous plaît fournir un exemple de travail d'une solution .Net Core 1.1.0 dans VS2017 (fichiers de projet .csproj) où l'explorateur de test VS trouve avec succès les tests unitaires OU me montrer le problème dans l'exemple donné.


J'ai découvert que VS2017 n'installe pas tous les packages requis. Lorsque j'ai essayé de déplacer mon MonoGame de l'ancien PC vers un nouveau avec Windows 10 et VS 2017 fraîchement installé, il a commencé à lancer des erreurs étranges sur les paquets manquants. Après l'installation de VS2015 avec VS2017, tous les problèmes ont disparu. Essayez peut-être d'installer VS2015 en plus.
Mateusz

2
Essayez d'installer des packages de tests avec le programme d'installation de Visual Studio
Markiian Benovskyi

Je cherche à savoir si VS 2017 a toutes les variables d'environnement correctement définies.
John Pezzanite

1
Pour NUnit, vous devez utiliser le package NuGet pour l'adaptateur et il doit être 3.8.0-alpha1 ou plus récent.
Rob Prouse

2
Dans mon cas, c'était la simple présence d'un app.configfichier dans mon projet de test: stackoverflow.com/a/47497668/67824 .
Ohad Schneider

Réponses:


189

Dans mon cas, il s'est avéré que je devais simplement mettre à niveau mes adaptateurs de test et mon framework de test. Terminé.

Exemple d'utilisation du gestionnaire de packages NuGet:

entrez la description de l'image ici


4
Cela m'a aussi aidé! Notez que vous pouvez "Gérer les packages Nuget" au niveau de la solution et le faire pour tous les projets où cela est requis. Vous pouvez alors obtenir des erreurs de «référence ambiguë» - pour celles-ci, supprimez simplement l'ancienne DLL (Microsoft.VisualStudio.QualityTools.UnitTestFramework) des références
Prashanth Subramanian

48
Ces choses devraient être des extensions de Visual Studio, pas des packages NuGet.
Jaider

1
Nous avons beaucoup d'anciens projets MSTest, et je ne savais pas qu'il était passé à un package NuGet. Cela l'a également résolu pour moi, pensant à l'origine que c'était un bug avec les nouvelles versions de ReSharper jusqu'à ce que je réalise que VS Test Explorer ne pouvait pas non plus découvrir mes tests.
David Anderson

1
J'ai fait exactement la même chose que cette réponse indique. Dans ma solution VS2017, j'ai ajouté un projet MSTest, ajouté quelques tests, mais la construction de la solution se traduirait par: Découvrir le test terminé: 0 trouvé. Ainsi, pour le projet de test, dans NuGet Package Manager (vous pouvez également le faire au niveau de la solution), j'ai mis à jour MSTest.TestAdapter et MSTest.TestFramework à la fois de la v1.1.18 à la v1.2.0. Ensuite, après avoir fait une construction, mes tests apparaissent maintenant dans l'Explorateur de tests.
Kershaw

1
Cela a très bien fonctionné pour moi, j'ai dû aller dans le gestionnaire de paquets nuget dans VS2017 pour le projet de test particulier et simplement mettre à jour les différents paquets que j'avais comme nunit, etc. puis construire> reconstruire et tout va bien.
Tahir Khalid

126

Cela a juste fonctionné pour moi (je ne sais pas si c'est le résultat de la modification des espaces de travail qui a corrompu quelque chose):

Suppression des fichiers de cache de test VS dans% TEMP% \ VisualStudioTestExplorerExtensions et redémarrez VS2017.


4
Cela a fonctionné une fois, pas après. Ce qui (cette fois) l'a corrigé pour moi, c'était la suppression du dossier TestResults et bin / obj (avec ce nettoyage du répertoire temporaire)
icesar

24
Quiconque se demande où %TEMP%- apporter la fenêtre de commande et taperecho %TEMP%
mike123

21
Le dossier n'existe pas en temp: /
Douglas Gaskell

alors quelle est la cause d'un tel comportement?
Mykhailo Seniutovych

1
Le moyen le plus simple d'accéder à% TEMP% est de gagner + R et de taper% TEMP%
PontiusTheBarbarian

58

L'API pour les adaptateurs de test pour .NET Core a changé avec la sortie de Visual Studio 2017 et le passage du project.jsonformat au csprojformat. Cela a rendu les dotnet-test-*adaptateurs existants dotnet-test-nunitobsolètes.

Les adaptateurs ont été mis à jour, mais la façon dont vous configurez et exécutez les tests dans Visual Studio ou sur la ligne de commande avec dotnet testnécessite des références différentes dans vos projets de test. Méfiez - vous de toute documentation que vous trouvez qui fait référence aux packages au dotnet-test-*format car ils sont obsolètes.

Tout d'abord, votre projet de test doit cibler une plate-forme spécifique, soit .NET Core ou .NET Framework. Il ne peut pas cibler .NET Standard même si le code que vous testez est .NET Standard. En effet, la cible des tests indique sous quelle plate-forme exécuter les tests. .NET Standard est comme une PCL (Portable Class Library) en ce sens qu'il peut fonctionner sur de nombreuses plates-formes.

Ensuite, vous devez ajouter des références à Microsoft.NET.Test.Sdk, votre cadre de test de choix et un adaptateur de test compatible. Pour NUnit, vos références ressembleront à ceci,

<itemgroup>
    <packagereference Include="Microsoft.NET.Test.Sdk" Version="15.0.0"></packagereference>
    <packagereference Include="NUnit" Version="3.7.1"></packagereference>
    <packagereference Include="NUnit3TestAdapter" Version="3.8.0"></packagereference>
</itemgroup>

Un commentaire ci-dessus mentionne l'ajout,

<ItemGroup>
    <Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
</ItemGroup>

Ce n'est pas strictement requis, mais peut aider. Il est ajouté automatiquement à tous les projets de test unitaire par Visual Studio pour l'aider à trouver rapidement des projets avec des tests.

Si vos tests n'apparaissent pas dans Visual Studio, la première chose à essayer est de fermer votre solution, puis de les rouvrir. Il semble y avoir des bogues dans Visual Studio qui ne détectent pas les modifications apportées aux projets lorsque vous les modifiez.

Pour plus d'informations, consultez Test de .NET Core avec NUnit dans Visual Studio 2017


2
Cibler .NET Framework plutôt que .NET Standard a fonctionné pour moi. Merci.
Ben Griswold

7
Cette référence Microsoft.NET.Test.SDK manquait dans mon projet et il n'y avait aucune indication nulle part que quoi que ce soit se soit appuyé sur elle pour s'afficher. Ajoutée via la console nuget et tout a commencé à fonctionner. Merci pour la liste de référence!
GWhite

J'ai dû copier ce dossier d'un collègue dans mon répertoire temporaire et redémarrer VS:% TEMP% \ VisualStudioTestExplorerExtensions \ MSTest.TestAdapter.1.1.18
Heiner

Comment puis-je tester un projet netstandard 2.0 si je change mon Framework cible? Je ne peux plus compiler car un projet netstandard2.0 ne peut pas être référencé par un projet qui tagge net46
Jerome2606

1
Cela a fonctionné pour moi. Merci pour la solution détaillée.
Talha Ashfaque

42

J'ai eu le même problème et l'ai fait fonctionner en procédant comme suit ..:

  • Fermez d'abord toutes les instances Visual Studio ouvertes et supprimez ce dossier:% TEMP% \ VisualStudioTestExplorerExtensions. ( Exécution de tests avec Visual Studio )
  • Accédez à votre gestionnaire de packages Nuget et installez d'abord Microsoft.NET.Test.Sdk (15.3.0-preview-20170425-07), puis installez xunit.runner.visualstudio (2.3.0-beta1-build1309). Voir la capture d'écran Nuget ci-jointe pour voir tous les packages que j'ai dû installer pour obtenir la dernière VS 2017 pour détecter mes tests.Capture d'écran de Nuget

35
La suppression de % Temp% \ VisualStudioTestExplorerExtensions m'a suffi.
Juan Pablo Gomez

Ouais. Le supprimer et redémarrer VS l'a corrigé.
Juan Carlos

Est-ce que quelqu'un sait ce qui cause cela en premier lieu? Je l'ai eu deux fois maintenant, mais la suppression de ce dossier et le redémarrage de VS ont fonctionné. C'est juste bizarre.
RubyHaus

@PmanAce - Je l'ai fait, en fait. J'utilise deux instances TFS différentes (une par projet), donc l'espace de travail change automatiquement lorsque je change de projet.
RubyHaus

la suppression du dossier et l'ajout du nuget Microsoft.NET.Test.Sdksemblaient fonctionner pour moi .. merci StackOverflow. (Solution .NET Framework WebApi 2)
bkwdesign

41

Oublier de rendre la classe de test publique empêche de découvrir les méthodes de test à l'intérieur

J'avais un projet xUnit par défaut et j'ai supprimé l'exemple UnitTest1.cs, en le remplaçant par une classe de test de contrôleur, avec quelques tests, mais aucun n'a été trouvé

Pour faire court, après avoir mis à jour les packages xUnit, Test.Sdk, xUnit.runner et reconstruit le projet, j'ai rencontré une erreur de build:

Erreur Les classes de test xUnit1000 doivent être publiques

Heureusement, la version mise à jour a levé cette exception pour m'épargner quelques ennuis

Modifier la classe de test pour qu'elle soit publique a résolu mon problème


6
Je ne sais pas pourquoi le vote a été rejeté, mais avant mon café du matin à 100%, j'ai été ignoré.
Andrei

1
J'ai essayé toutes les autres réponses à cette question / problème et c'est celle qui a finalement fonctionné!
FastTrack

3
Celui-là est incroyablement embarrassant mais ... peu importe. La chose hilarante est que si vous créez un cas de suite de tests dans VS2017, il ne générera pas la publicclasse, mais juste la classe, donc il ne le découvrira pas tant que vous n'ajoutez pas l' publicidentifiant.
briosheje

bien sûr. mon mauvais - mstest devrait avoir cette fonctionnalité.
Crismogram

10

Dans mon cas, je cible le projet de test sur x64Architecture et le paramètre de test Architecture (test-> Default Processor Architecture) modifié a été défini sur x86. Ils ne correspondaient pas.

Après avoir rétabli le paramètre de test Architecture x64et reconstruit tous les tests ont été découverts à nouveau.


dans vs2017, le paramètre dans le menu Test -> Paramètres de test -> Architecture de processeur par défaut
IcyBrk

8

J'ai également eu du mal avec VS 2017 à trouver mon UnitTest. Ce n'était pas exactement le problème que John demandait - mais c'était le premier résultat sur Google que je cherchais, alors je voulais partager mon problème.

J'avais une solution héritée revenant de VS2010 passant par VS2013, VS2015. Maintenant, dans VS2017, les espaces de noms de l' [TestMethod]attribut semblent avoir changé.

Avant d'utiliser

Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0

J'ai créé un nouveau Test.dll dans le projet et celui utilisé par défaut

Microsoft.VisualStudio.TestPlatform.TestFramework, Version=14.0.0.0

Ma solution a donc été de créer un nouveau projet UnitTest à partir de VS2017. Peut-être que la modification des références d'assemblage pour l'ancien projet de test aurait également fonctionné. Avec la nouvelle référence, VS2017 a découvert ces tests unitaires.


Malheureusement, même un nouveau projet de test unitaire n'a pas son test pour moi: /
Douglas Gaskell

7

Ne lisez pas les articles périmés sous MSDN. Les documents pertinents pour .NET Core se trouvent sous docs.microsoft.com

https://docs.microsoft.com/en-us/dotnet/articles/core/testing/

De manière générale, vous avez besoin d'une application console .NET Core pour contenir les cas de test unitaire.


Merci beaucoup, Lex. Si cet article est correct, la seule façon de tester .NET Core est à partir de la ligne de commande - perdant ainsi toute l'intégration VS que nous avons eu avec l'exécution de tests dans VS 2015. Suis-je correct à ce sujet?
John Pezzanite

Utilisez-vous xUnit.net ou MSTest?
Lex Li

@JohnPezzanite vous devez montrer plus de ce que vous avez fait (probablement un repo GitHub si possible). J'ai des projets chez GitHub qui fonctionnent parfaitement, et bien d'autres aussi.
Lex Li

Suivez l'exemple de la ligne que j'ai fournie. Je l'ai essayé avec .NET standard et .NET Core, avec les tests unitaires de Microsoft comme dans l'exemple et avec xUnit. La norme .NET s'intègre à VS 2017 tandis que .NET Core ne s'exécutera qu'à partir de la ligne de commande. Mais je répète ce que j'ai dit ci-dessus. Il semble que Microsoft ait supprimé tous les formulaires d'intégration de tests unitaires .NET Core VS 2017.
John Pezzanite

@JohnPezzanite test GitHub.com/lextm/sharpsnmplib et sa solution NetStandard.
Lex Li

6

pour moi, le problème était que j'ai placé par erreur des testcases dans une classe interne

[TestClass]
  internal class TestLib {
}

qui provoquait la non-identification des cas de test.


5

Assurez-vous que vous utilisez le bon Microsoft.NET.Test.Sdk:

<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />

N'utilisez pas une version préliminaire. Ou vous devez passer à l'application console (pas à la bibliothèque). J'ai le même problème, mais avec la dernière version (15.0.0), il recommence à fonctionner.

Vous devrez peut-être également ajouter:

  <ItemGroup>
    <Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
  </ItemGroup>

mais je ne pense pas que ce soit nécessaire.


Dans quel fichier se trouve-t-il? Je peux trouver la partie "Service Include" dans mon fichier de projet (* .csproj) mais pas le PackageReference.
Chris Bennet

@ChrisBennet dans votre fichier * test.csproj.
Evgeni Nabokov

1
@ evgeni-nabokov a raison. Toutes ces modifications se trouvent dans le fichier [project] .test.csproj. Faites un clic droit sur le projet dans la solution et sélectionnez "Modifier [projet] .test.csproj" Voir l'exemple sur: github.com/RenetConsulting/angularcore.net/blob/master/Business/…
Alex Altotsky

5

Je sais que OP l'a répertorié sur sa liste de contrôle, mais il est facile d'oublier ce point tout en faisant une installation propre de Visual Studio 2017 et en configurant un nouveau projet. Outre le modèle de projet NUnit et NUnit Framework, il faut installer l'adaptateur NUnit séparément, par exemple en utilisant la commande NuGet Install-Package NUnit3TestAdapter -Version 3.9.0. Après cela, Visual Studio Community 2017 a commencé à découvrir les tests unitaires sans aucun problème.


1
Cela m'a aidé!
YvesR

OMG, celui-ci l'a fait pour moi. Si je pouvais vous arroser de primes, je le ferais.
Ash

C'était la seule solution qui a fonctionné pour moi, merci!
Vadim Tofan

5

Dans mon cas, l'Explorateur de tests n'a pas pu trouver mes tests après avoir déplacé le projet vers une nouvelle solution.

La réponse était simplement que j'avais une référence à l'ancien MS Test Adapter dans mon projet.

J'ai eu un doublon de la ligne ci-dessous pour la version 1.1.11 de l'adaptateur de test MS dans mon fichier cs.proj:

<Import Project="..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.props" Condition="Exists('..\packages\MSTest.TestAdapter.1.1.18\build\net45\MSTest.TestAdapter.props')" />

Pour résoudre le problème,

  1. Faites un clic droit sur le projet et sélectionnez «Décharger le projet».
  2. Cliquez avec le bouton droit sur le projet et sélectionnez «Modifier»
  3. Supprimez la ligne qui importe l'ancienne version de l'adaptateur.
  4. Faites un clic droit sur le projet et sélectionnez «Recharger le projet».
  5. Reconstruire la solution / le projet

Eu le même problème. La suppression et la reconstruction de la solution n'ont pas fonctionné. VS redémarrés et tests ont été découverts!
Mike Ward

4

J'ai juste eu ce problème avec visual studio incapable de trouver mes tests, je n'ai pas pu voir le bouton pour les exécuter en plus de la méthode, et ils n'ont pas été détectés en exécutant tous les tests du projet.

Il s'avère que ma classe de test n'était pas publique! Le rendre public a permis à VS de découvrir les tests.


2

Pour moi, il était plus facile de créer un nouveau projet de test qui fonctionne parfaitement avec Visual Studio 2017 ... et de simplement copier les fichiers de test, ajouter des références et des packages NuGet selon les besoins.

entrez la description de l'image ici


la création d'un nouveau projet a probablement sauvé des heures de maux de tête!
M.kazem Akhgary

2

Dans mon cas, c'était un projet que j'avais mis à niveau le projet de test d'une version antérieure de .Net. dans l'app.config, j'avais des liaisons d'assemblage aux versions précédentes des assemblages dépendants.

Après avoir corrigé les liaisons d'assemblage dans le fichier app.config, mes tests ont été découverts.


2

Découverte

Les meilleures réponses ci-dessus n'ont pas fonctionné pour moi (redémarrage, mise à jour vers la version 1.1.18 ... j'étais déjà mis à jour, suppression des fichiers temporaires, effacement du cache NuGet, etc.).

Ce que j'ai découvert, c'est que j'avais des références différentes à MSTest.TestAdapter et MSTest.Framework dans différents projets de test (ma solution en a deux). On a été pointé au 1.1.18 comme ...

packages.config

<package id="MSTest.TestAdapter" version="1.1.18" targetFramework="net461" />
<package id="MSTest.TestFramework" version="1.1.18" targetFramework="net461" />

... mais un autre fait référence au 1.1.11. Certaines des réponses ci-dessus conduisent à cette découverte lorsque deux versions des bibliothèques sont apparues dans mon répertoire temporaire (% TEMP% \ VisualStudioTestExplorerExtensions \) après le redémarrage de Visual Studio.

Solution

La simple mise à jour de packages.config vers la version 1.1.18 est ce qui a restauré la fonctionnalité de tests unitaires dans VS. Il semble que certains bogues n'autorisent pas les références côte à côte des bibliothèques MSTest. J'espère que cela vous aidera.

Plus d'informations:

  • Visual Studio 2017 Ent: 15.5.6 (j'avais mis à jour à partir de 15.0.1 avec l'espoir de résoudre ce problème, mais je l'avais dans les deux)

2

La solution consistait à supprimer mon app.configfichier de mon projet de test unitaire. Les tests réapparaîtront!

Ce fichier a référencé certaines DLL dans les bindredirects qui n'étaient pas réellement présentes dans les références du projet. Ajoutez à nouveau les assemblages qui sont strictement nécessaires à votre projet.


1

Dans mon cas, c'est le projet UWP présent dans la solution à l'origine du problème.

Lorsque j'ai déchargé le projet UWP, des tests ont été découverts. Lorsque je l'ai rechargé, le test a de nouveau disparu.

Essayez de décharger tous les projets et de conserver le projet de test uniquement. Dix solutions de reconstruction et shound de test apparaissent dans Test Runner. Chargez les projets un par un et reconstruisez la solution à chaque fois pour savoir quel projet est à l'origine du problème

échantillon repo

Rapport de bogue VS


Appréciez la réponse mais ce n'est pas mon problème. Si vous regardez l'exemple de référentiel auquel j'ai lié dans ma question, il n'y a qu'un seul projet dans la solution. Il n'y a pas d'autres projets à supprimer. Cette solution est un test, alors j'ai essayé ce que vous avez dit décharger des projets sur ma solution actuelle, mais cela n'a pas fonctionné.
rayepps

1

Le problème

Le problème est que Visual Studio devient «confus» sur les versions de base dotnet sur la machine. Lorsque je suis allé dans le panneau de configuration -> désinstaller des programmes, 8 SDK et Runtimes core dotnet différents ont été installés. Cela provoquait en quelque sorte une erreur silencieuse de VS lors de la recherche de tests.

Valider le problème

Vous pouvez valider le problème en accédant à la ligne de commande et en activant la version de dotnet $ dotnet --version. Si vous voyez quoi que ce soit, à l'exception de la dernière version que vous avez installée, votre machine présente un certain décalage et n'utilise pas la bonne version. Exemple ... Si vous avez 1.0.1installé le noyau dotnet mais lorsque vous obtenez la version à l'invite de commande et que 1.0.0c'est un problème.

La solution

Supprimez tous les anciens éléments. J'ai commencé avec seulement ce que je pensais avoir besoin de supprimer (les plus anciennes versions de dotnet rc) mais cela donnait toujours la mauvaise version lors du test du problème. Finalement, j'ai concédé de faire un nettoyage complet. JE...

  • Désinstallation de toutes les applications Visual Studio (sur ma machine VS2015 et VS2017)
  • Désinstallé toutes les versions de dotnet core (même les plus récentes)

Après que ma machine était complètement vide de tous les VS et donet, j'ai installé seulement VS2017 (il est livré avec le dernier dotnet). J'ai créé un projet de test xUnit et l'explorateur de tests a trouvé le test immédiatement RÉSOLU

Cela peut sembler exagéré, mais j'ai passé deux semaines à essayer de résoudre ce problème par d'autres moyens. Si vous rencontrez le problème, faites-le, même si cela peut vous prendre des heures pour désinstaller / réinstaller des éléments, cela vous fera probablement gagner du temps.

Références

  • Voir l'article de blog @epestic où il donne plus de détails sur la résolution du problème.

1

J'ai tout essayé mais rien n'y fait. Dans mon cas, j'avais une solution avec plusieurs projets de test et certains d'entre eux utilisaient l'ancien framework ms-test, donc Visual Studio n'a trouvé que ceux-ci.

J'ai installé les packages de framework de test pour tous les projets de test, comme indiqué dans la réponse acceptée . Puis supprimé les références aux anciens outils de qualité, redémarré Visual Studio et maintenant je peux voir tous les tests.


1

Pour C ++:

Comme il n'y a pas de question spéciale pour les tests C ++, mais le sujet est à peu près le même, voici ce qui m'a aidé lorsque j'ai eu des problèmes avec la découverte de tests.

Si vous avez uniquement installé le développement Desktop avec C ++ , la solution consiste à installer également le développement Universal Windows Platform avec les outils facultatifs C ++ Universal Windows Platform . Vous pouvez les sélectionner dans le programme d'installation Web de Visual Studio.

Ensuite, reconstruisez votre projet de test et la découverte de test devrait fonctionner.

Btw, j'ai créé le projet de test unitaire dans VS2017. Il peut être important, car certains utilisateurs ont mentionné, qu'ils avaient des problèmes de découverte dans les projets, qui ont été migrés de VS2015 vers VS2017.


1

La suppression des anciens fichiers .dll devrait aider. Effacement des fichiers temporaires situés dans le répertoire% TEMP% dans C: \ Users (votre nom d'utilisateur) \ AppData \ Local \ Temp


1

J'ai eu le même problème. Ma solution était OK, mais soudainement, lorsque j'ai ouvert la solution, j'ai découvert que les tests avaient disparu.

Enfin, j'ai rétrogradé Microsoft.VisualStudio.TestPlatform.TestFrameworket des Microsoft.VisualStudio.TestPlatform.TestFramework.Extensionspackages vers une très ancienne version (en utilisant le gestionnaire NuGet) et des méthodes de test sont apparues. Ensuite, je suis passé à la dernière version et il y en avait toujours.

Il suffit donc de rétrograder et de mettre à niveau les packages.


1

Dans mon cas, rien de ce qui précède ne m'aide. Mais, je rétrograde NUNit3TestAdapter à la version 3.8.0, puis passe à la dernière (3.10.0)


1

Parfois, la modification de l'espace de noms des tests fonctionne. J'avais la structure des dossiers comme suit:

A |___B | |___D |___C___E

L'espace de noms était plat comme Tests. <Nom> et ils n'apparaissaient pas dans la fenêtre de test. Lorsque j'ai changé l'espace de noms pour la structure du répertoire, tous les tests sont apparus. Maintenant, je pouvais revenir à toute autre structure d'espace de noms que je voulais.

N'oubliez pas de construire votre projet!


1

Dans le cas de .NET Framework, dans le projet de test, il y avait auparavant des références aux DLL suivantes:

Microsoft.VisualStudio.TestPlatform.TestFramework
Microsoft.VisualStudio.TestPlatform.TestFramework.Extentions

Je les ai supprimés et j'ai ajouté une référence à:

Microsoft.VisualStudio.QualityTools.UnitTestFramework

Et puis tous les tests sont apparus et ont commencé à fonctionner de la même manière qu'auparavant.

J'ai essayé presque toutes les autres suggestions ci-dessus auparavant, mais simplement le re-référencement des DLL de test a bien fonctionné. J'ai posté cette réponse pour ceux qui sont dans mon cas.


1

Je faisais face au même problème, dans mon cas afin de résoudre

  1. J'ai ouvert la console Windows (touche Windows + cmd).
  2. Accédez au dossier dans lequel le projet a été créé.
  3. Exécuté la commande "test dotnet" c'est fondamentalement le même test que Visual Studio exécute mais lorsque vous l'exécutez via la console il vous permet de voir la trace complète.
  4. J'ai reçu ce message d'erreur "Attribut TestClass défini sur la classe non publique MSTest.TestController.BaseTest"
  5. Je suis donc allé dans le cas de test et le marquer comme public, reconstruire à nouveau et mes tests s'affichent correctement

0

Au début, j'ai essayé d'utiliser MSTest. Après cela, je le change en test Nunit. Ensuite, je voulais soutenir MSTest. J'ai supprimé tous les codes et références nUnit, mais Test Explorer n'affichait pas les méthodes MSTest. Solution: j'ai supprimé toutes les références de nuget mstest et réinstallé. Terminé.


0

Pour moi, changer le TargetFramework dans le .csprojfichier du projet de test de

  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>

à

  <PropertyGroup>
    <TargetFramework>net46</TargetFramework>
  </PropertyGroup>

travaillé.


0

Dans mon cas, le problème était que le type de projet était défini sur une bibliothèque statique (lib), et il devrait s'agir d'une bibliothèque dynamique (dll)

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.