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

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:

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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)

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.

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

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.

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.

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.

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

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.

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)

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!

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.

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

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

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

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)