Tests unitaires non découverts dans Visual Studio 2017
Je me bats avec VS 2017 depuis que je l'ai installé. Maintenant, il semble que les tests unitaires ne seront lancé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 de la même manière.
Tous les packages NuGet pour les tests et le projet principal sont à jour. Et le projet test et le projet principal sont tous deux construits sans erreur. Les tests sont exécutés avec succès à partir de la ligne de commande.
Quelqu'un a-t-il obtenu des tests unitaires pour VS 2017? Si oui, comment?
Merci, John
Mettre à jour - Étendre
Voici un exemple de 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 je fais, je ne peux pas demander au coureur de tests du VS de trouver des tests.
Ce que j'ai essayé
- Suppression de fichiers de cache de test VS
DEL %TEMP%\VisualStudioTestExplorerExtensions - Redémarrage de VS
- Fermeture/ouverture du test explorateur
- pour xUnit installé
Microsoft.DotNet.InternalAbstractions( voir SO post ) - pour NUnit, assurez-vous que l’adaptateur est installé et que la même version (3) que le paquet NUnit
test -> test settings -> default processor architectureest défini sur x86
La question
Quelqu'un peut-il fournir un exemple concret de solution .Net Core 1.1.0 dans VS2017 (fichiers de projet .csproj) où l'explorateur de tests VS a réussi à trouver les tests unitaires OU exemple donné.
Dans mon cas, il est apparu que je devais simplement mettre à niveau mes adaptateurs de test et ma structure de test. Terminé.
Exemple d'utilisation du gestionnaire de paquets 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 ont corrompu quelque chose):
Supprimez les fichiers de cache de test VS dans% TEMP%\VisualStudioTestExplorerExtensions et redémarrez VS2017.
L'API pour les adaptateurs de test pour .NET Core a été modifiée avec la publication de Visual Studio 2017 et le passage du format project.json au format csproj. Cela rend les adaptateurs dotnet-test-* existants tels que dotnet-test-nunit obsolètes.
Les adaptateurs ont été mis à jour, mais la manière dont vous configurez et exécutez des tests dans Visual Studio ou sur la ligne de commande avec dotnet test nécessite des références différentes dans vos projets de test. Méfiez-vous de toute documentation dans laquelle vous trouvez ces packages de référence au format dotnet-test-* car ils sont obsolètes.
Tout d’abord, votre projet de test doit cibler une plate-forme spécifique, .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 sur quelle plate-forme les tests doivent être exécutés. .NET Standard est comme une bibliothèque de classes portable (PCL) dans la mesure où il peut fonctionner sur de nombreuses plates-formes.
Ensuite, vous devez ajouter des références à Microsoft.NET.Test.Sdk, à votre framework de test 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 nécessaire, mais peut aider. Il est ajouté automatiquement à tous les projets de test d'unité 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 à faire 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, voir Test de .NET Core avec NUnit dans Visual Studio 2017
J'ai eu le même problème et je l'ai obtenu au travail en faisant ce qui suit ..:
- Commencez par fermer toutes les instances Visual Studio ouvertes et supprimez ce dossier:% TEMP%\VisualStudioTestExplorerExtensions. ( Exécution de tests avec Visual Studio )
- Accédez au gestionnaire de paquets 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 paquets que j'ai dû installer pour que le dernier VS 2017 détecte mes tests .
![Nuget Screenshot]()
Oublier de rendre la classe de test publique empêcher que les méthodes de test à l'intérieur ne soient découvertes
J'avais un projet par défaut xUnit 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é.
Bref récit, après la mise à jour des packages xUnit, Test.Sdk, xUnit.runner et la reconstruction du projet, une erreur de construction s'est produite:
Les classes de test d'erreur xUnit1000 doivent être publiques
Heureusement, la version mise à jour a jeté cette exception pour m'épargner quelques ennuis
La modification de la classe de test pour qu'elle soit publique a corrigé mon problème.
Dans mon cas, je cible le projet de test sur x64 Architecture et le paramètre Architecture de test (test-> Architecture du processeur par défaut) modifié a été défini sur x86. Ils ne correspondaient pas.
Après avoir rétabli le paramètre de test Architecture sur x64 et reconstruit tous les tests ont été découverts à nouveau.
Ne lisez pas les articles périmés sous MSDN. Les matériaux pertinents pour .NET Core sont sous docs.Microsoft.com
https://docs.Microsoft.com/en-us/dotnet/articles/core/testing/
En règle générale, vous avez besoin d'une application de console .NET Core pour contenir les cas de test unitaires.
VS 2017 avait également du mal à trouver mon UnitTest. Ce n’était pas le problème exact que John demandait - mais c’était le premier résultat que je recherchais dans Google, je voulais donc partager mon problème.
J'ai eu une solution héritée de VS2010 passant de VS2013 à VS2015. Maintenant, dans VS2017, il semble que les espaces de noms pour l'attribut [TestMethod] aient changé.
Avant il utilisait
Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0
J'ai créé un nouveau Test.dll dans le projet et celui-ci 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. Changer les références de l’Assemblée pour l’ancien projet-test aurait peut-être également fonctionné. Avec la nouvelle référence, VS2017 a découvert ces tests unitaires.
Assurez-vous que vous utilisez le bon fichier Microsoft.NET.Test.Sdk:
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />
Ne pas utiliser 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.
En outre, vous devrez peut-être ajouter:
<ItemGroup>
<Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}" />
</ItemGroup>
mais je ne pense pas que ce soit nécessaire.
Je sais qu'OP a inscrit cela sur sa liste de contrôle, mais il est facile de négliger ce point lors d'une nouvelle installation de Visual Studio 2017 et de la configuration d'un nouveau projet. Outre les modèles de projet NUnit et NUnit Framework , vous devez 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.
pour moi la question a été jai placé par erreur testcases dans une classe interne
[TestClass]
internal class TestLib {
}
cela causait que les cas de test ne soient pas identifiés.
Découverte
Les principales 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 comporte deux). On a pointé à 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 a les références à 1.1.11. Certaines des réponses ci-dessus mènent à 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
Mettre à jour simplement packages.config vers la version 1.1.18 est ce qui a restauré la fonctionnalité de test de mon unité 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 aide.
Plus d'informations:
- Visual Studio 2017 Ent: 15.5.6 (j'avais mis à jour à partir de 15.0.1 dans l'espoir de résoudre ce problème, mais je l'avais dans les deux)
Dans mon cas, c’était un projet que j’avais mis à niveau le projet test à partir d’une version antérieure de .Net. dans le fichier app.config, j'avais des liaisons d'assemblage aux versions précédentes des assemblys dépendants.
Après avoir corrigé les assembnlybindings dans le fichier app.config, mes tests ont été découverts.
Vient juste ce problème avec Visual Studio, incapable de trouver mes tests, je ne pouvais pas 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 les packages NuGet selon les besoins.
Dans mon cas, le projet UWP était présent dans la solution à l'origine du problème.
Lorsque j'ai déchargé le projet UWP, des tests ont été découverts. Quand je l'ai chargé, test a disparu à nouveau.
Essayez de décharger tous les projets et ne gardez que le projet test. Dix solutions de reconstruction et de test shound 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
Pour C++:
Comme il n’ya pas de question spéciale pour les tests C++, mais que le sujet est très similaire, voici ce qui m’a aidé lorsque j’ai eu du mal à déceler les tests.
Si vous avez uniquement installé développement avec C++, la solution consiste également à installer développement de la plate-forme Windows universelle avec les outils facultatifs outils C++ de la plate-forme Windows universelle. 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. Certains utilisateurs ont indiqué qu'il était peut-être important qu'ils rencontraient des problèmes de découverte dans les projets, migrés de VS2015 à VS2017.
Supprimer les anciens fichiers .dll devrait vous aider. Effacement des fichiers temporaires situés dans le répertoire% TEMP% sous C:\Users (votre nom d'utilisateur)\AppData\Local\Temp
En ce qui me concerne, rien de ce qui précède ne m’aide… . Mais, je rétrograde NUNit3TestAdapter vers la version 3.8.0, puis mets à niveau vers la dernière version (3.10.0).
J'ai eu le même problème. Ma solution était correcte, mais tout à coup, lorsque j'ai ouvert la solution, j'ai découvert que les tests avaient disparu.
Finalement, j'ai rétrogradé les paquets Microsoft.VisualStudio.TestPlatform.TestFramework et Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions vers une version très ancienne (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 des paquets.
La solution supprimait mon fichier app.config de mon projet de test unitaire. Les tests vont réapparaître!
Ce fichier a référencé des dll dans le bindingredirect qui n'étaient pas réellement présentes dans les références du projet Ajoutez à nouveau les liaisons d'assemblage strictement nécessaires à votre projet.
J'ai tout essayé mais rien n'a aidé. Dans mon cas, j'avais une solution avec plusieurs projets de test et certains d'entre eux utilisaient l'ancien framework ms-test, Visual Studio n'a donc trouvé que ceux-ci.
J'ai installé les packages de cadre de test pour tous les projets de test, comme indiqué dans la réponse acceptée . Supprimez ensuite les références aux anciens outils de qualité, redémarrez Visual Studio et je peux maintenant voir tous les tests.
Dans mon cas, le problème était que le type de projet était défini sur bibliothèque statique (lib) et que cela devait être une bibliothèque dynamique
Vérifiez si l'adaptateur de test NUnit 3 est activé. Dans mon cas, je l’avais déjà installé il y a longtemps, mais tout à coup, il a été désactivé. Il m'a fallu un bon bout de temps avant que je décide de vérifier cette partie ...
Parfois, changer l’espace de noms des tests fonctionne. J'ai eu la structure de dossier comme suit:
A
|___B
| |___D
|___C___E
L'espace de noms était plat, à la manière de Tests. <Nom> et ils n'apparaissaient pas dans la fenêtre de test. Lorsque j'ai modifié l'espace de noms en fonction de la structure du répertoire, tous les tests sont apparus. Je peux maintenant revenir à toute autre structure d'espace de noms que je veux.
N'oubliez pas de construire votre projet!
Parfois, je constate que si votre code de test unitaire contient des exceptions stackoverflow, Visual Studio marquera ce scénario de test d'unité comme non exécuté et cessera d'exécuter d'autres scénarios de test suivant ce scénario.
Dans ce cas, vous devez savoir quel cas est à l'origine de l'exception stackoverflow.
J'ai supprimé les dossiers BIN et OBJ du projet. Une fois que j'ai fait cela, tout a fonctionné correctement.
Au début, j'ai essayé d'utiliser MSTest. Après cela, je le change en test Nunit. Ensuite, je voulais sauvegarder MSTest. J'ai supprimé tous les codes et références nUnit mais Test Explorer n'a pas montré les méthodes MSTest. Solution: J'ai supprimé toutes les références de pépites mstest et les ai réinstallées. Terminé.
Pour moi, changer le TargetFramework dans le fichier .csproj du projet test de
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
à
<PropertyGroup>
<TargetFramework>net46</TargetFramework>
</PropertyGroup>
travaillé.
Dans le cas de .NET Framework, dans le projet de test, il y avait autrefois des références aux DLL suivantes:
Microsoft.VisualStudio.TestPlatform.TestFramework
Microsoft.VisualStudio.TestPlatform.TestFramework.Extentions
Je les ai supprimés et 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 déjà essayé presque toutes les autres suggestions ci-dessus, mais il a simplement fonctionné de refaire référence aux DLL de test. J'ai posté cette réponse pour ceux qui sont dans mon cas.
Le problème
Le problème est que Visual Studio est en train de devenir «confus» par rapport aux versions de base de Dotnet sur la machine. Quand je suis allé dans le panneau de configuration -> désinstaller des programmes, j'avais 8 SDK et Runtimes Core Dotnet différents installés. Cela causait en quelque sorte une erreur à VS lorsqu’il essayait de trouver des tests.
Valider le problème
Vous pouvez valider le problème en accédant à la ligne de commande et en obtenant la version de dotnet votre $ dotnet --version. Si vous voyez autre chose que la version la plus récente que vous avez installée, votre ordinateur présente des incohérences et n'utilise pas la version correcte. Exemple ... Si vous avez le noyau dotnet 1.0.1 installé, mais que vous obtenez la version à l'invite de commande et qu'il indique 1.0.0, c'est un problème.
La solution
Supprimer tous les vieux trucs. J'ai commencé avec seulement ce que je pensais avoir besoin de supprimer (les versions les plus anciennes de rc dotnet), mais il donnait toujours la mauvaise version lors du test du problème. Finalement, j'ai concédé pour faire un nettoyage complet. JE...
- Désinstallation de toutes les applications de Visual Studio (sur ma machine VS2015 et VS2017)
- Désinstallez toutes les versions de dotnet core (même les plus récentes)
Après que ma machine ait été complètement vide de tous les VS et que je n'ai pas 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&EACUTE;SOLU
Cela peut sembler exagéré, mais j'ai passé deux semaines à essayer de régler le problème autrement. Si le problème persiste, même si cela peut vous prendre des heures pour désinstaller/réinstaller des éléments, vous gagnerez probablement du temps.
Références
- Voir @epestic blog post où il donne plus de détails sur la résolution du problème.