Visual Studio 2015 ou 2017 ne découvre pas les tests unitaires
EDIT 2016-10-19:
La question initiale portait sur un problème spécifique à VS2015 CTP6 avec le programme d'exécution de test XUnit. Il ressort clairement des réponses qu'il existe un problème beaucoup plus vaste lié à la découverte de tests unitaires dans Visual Studio, qui peut se produire dans de nombreuses situations différentes. J'ai nettoyé ma question pour refléter cela.
J'ai également inclus un script dans ma propre réponse, que j'utilise encore à ce jour pour résoudre des problèmes similaires lorsqu'ils apparaissent.
De nombreuses autres réponses se sont également révélées utiles pour mieux comprendre les subtilités du coureur de test VS. J'apprécie que les gens partagent encore leurs solutions!
Question originale 2015-04-10:
Depuis hier, Visual Studio Test Explorer ne détecte aucun test pour aucun de mes projets. Il ne montre pas non plus la barre de chargement verte après la construction.
Lorsque je vais dans l'explorateur de tests Visual Studio et que je clique sur "Tout exécuter", ou que je clique avec le bouton droit de la souris sur une méthode de test et que je sélectionne "Exécuter les tests", le message suivant s'affiche dans la fenêtre de sortie:
Could not load file or Assembly 'Microsoft.VisualStudio.Web.ProjectSystem, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
J'exécute Visual Studio 2015 CTP 6 sur Windows 10 Pro Technical Preview, version 10041. La version de .NET Framework ne semble pas avoir d'importance - cela se produit sur 4.0, 4.5.2 et 4.6.
J'ai essayé avec les frameworks de test suivants et tous donnent le même comportement:
Microsoft.VisualStudio.QualityTools.UnitTestFramework v14.0.22609.0xunit v2.1.0-beta1-build2945avecxunit.runner.visualstudio v2.1.0-beta1-build1051NUnit v2.6.4avecNUnitTestAdapter v2.0.0
J'ai trouvé un problème sur GitHub (xunit) qui semblait être similaire: Impossible de détecter les tests découverts # 295 , avec ce commentaire de l'équipe xunit:
Sachez que Visual Studio 2015 CTP 5 a été signalé en panne par de nombreuses personnes ayant des tests unitaires en général (pas seulement xUnit.net), donc ne vous attendez pas à ce que cela fonctionne.
Assurez-vous également que vous avez nettoyé le coureur de Visual Studio cache. S'il est corrompu, Visual Studio se comportera de manière irréversible jusqu'à ce qu'il soit supprimé. Pour vider le cache, fermez toutes les instances de Visual Studio, puis supprimez le dossier % TEMP%\VisualStudioTestExplorerExtensions (honnêtement, il est probable que Ne ferait pas de mal à tout supprimer dans% TEMP% pouvant être supprimé).
J'ai essayé leur suggestion de supprimer le dossier %TEMP%\VisualStudioTestExplorerExtensions. Malheureusement, cela n'a pas résolu le problème.
J'ai remarqué que ReSharper est en mesure de découvrir certains tests. Cela ne fonctionne que pour les tests VS et NUnit, pas pour xunit.
Il faut qu'il y ait une sorte de dossier temporaire ou de cache que je dois effacer, mais je sais que Visual Studio en contient beaucoup et que tous ne peuvent pas être supprimés sans effets secondaires indésirables.
EDIT 2016-10-19 (script PowerShell)
Ce problème revient toujours de temps en temps. J'ai écrit un petit extrait de code PowerShell pour automatiser le nettoyage du cache/du dossier temporaire/des fichiers correspondants. Je le partage ici pour les futurs lecteurs:
@(
"$env:TEMP"
"$env:LOCALAPPDATA\Microsoft\UnitTest"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\1033\SpecificFolderCache.xml"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\1033\ProjectTemplateMRU.xml"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\ComponentModelCache"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\Designer\ShadowCache"
"$env:LOCALAPPDATA\Microsoft\VisualStudio\14.0\ImageLibrary\cache"
"$env:LOCALAPPDATA\Microsoft\VisualStudio Services\6.0\Cache"
"$env:LOCALAPPDATA\Microsoft\WebsiteCache"
"$env:LOCALAPPDATA\NuGet\Cache"
) |% { Remove-Item -Path $_ -Recurse -Force }
Assurez-vous de fermer Visual Studio à l’avance. C’est probablement une bonne idée de redémarrer ultérieurement.
La suppression du dossier TEMP peut ne pas être nécessaire et même dans certains cas être indésirable. Je vous recommande donc d'essayer sans effacer le dossier TEMP au préalable. Oubliez simplement le "$env:TEMP".
Réponse originale le 12/04/2015
Le problème a été "résolu" après un nettoyage approfondi des dossiers temp/cache liés à Visual Studio.
Comme je n’ai pas eu le temps de tout parcourir un par un, puis de faire des essais entre les deux, je ne sais malheureusement pas lequel a réellement causé le problème.
Ce sont les mesures exactes que j'ai prises:
- Fermé Visual Studio
- CCleaner utilisé pour effacer les fichiers/dossiers du système et du navigateur
temp Supprimez/supprimez manuellement les fichiers/dossiers suivants:
%USERPROFILE%\AppData\Local\Assembly%USERPROFILE%\AppData\Local\Microsoft\UnitTest%USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\1033\SpecificFolderCache.xml%USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\1033\ProjectTemplateMRU.xml%USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\ComponentModelCache%USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\Designer\ShadowCache%USERPROFILE%\AppData\Local\Microsoft\VisualStudio\14.0\ImageLibrary\cache%USERPROFILE%\AppData\Local\Microsoft\VisualStudio Services\6.0\Cache%USERPROFILE%\AppData\Local\Microsoft\WebsiteCache%USERPROFILE%\AppData\Local\NuGet\Cache%USERPROFILE%\AppData\Local\Temp
À ma grande surprise, effacer les fichiers temporaires situés dans le répertoire %TEMP% a résolu le problème pour moi.
Remarque: Ce chemin est généralement à C:\Users\(yourusername)\AppData\Local\Temp
Comme @ Warren-P inclus, vous pouvez accéder au dossier temporaire en mettant %temp% dans le menu Démarrer, ou lancer "Explorateur de fichiers" et entrer %temp% dans la barre d'adresse.
Il se peut que vos codes soient compilés avec x64. Par conséquent, vous devez activer l'architecture de processeur par défaut en tant que X64.
Test > Test Settings > Default Processor Architecture > X64
Vérifiez si NUnit Test Adapter 2/3 est installé dans VisualStudio.
(Tools>Extensions and Updates )Assurez-vous que la bonne architecture de processeur est choisie:
(Test>Test Settings>Default Processor Architecture)
Une des raisons de ce problème est que votre classe de test n'est pas publique. MSTest découvre uniquement les tests des classes publiques.
Dans Visual Studio 2015 (mise à jour 3), si vous souhaitez associer les tests à l’explorateur de tests, vous devez installer l’adaptateur NUnit Test Adapter . Téléchargez l’adaptateur à partir de Outils-> Extension et mises à jour devez rechercher l’adaptateur) -> Télécharger . En redémarrant Visual Studio, vous pouvez voir les modifications apportées à la structure de test.
Je n'ai pas de réponse complète à cela, mais j'ai déterminé certaines choses en jouant avec un projet test:
- Le
xunit.runner.aspnet : 2.0.0-aspnet-beta4qui semble faire partie de la version officielle beta4 aspnet5 ne fonctionne pas dans Visual Studio. - À la place, l'utilisation des packages
"xunit": "2.1.0-*"et"xunit-runner.dnx": "2.1.0-*"fonctionne dans Visual Studio. - Pour que VS puisse découvrir les tests, votre projet DOIT avoir une seule commande nommée "test" qui exécute "xunit.runner.dnx". L'ajout de commandes supplémentaires peut le casser.
- Si votre fenêtre Test Explorer finit toujours par être vide, RETIREZ la commande "test" de votre projet, puis reconstruisez la solution, puis ajoutez la commande "test" au projet.json.
- Effacer toutes vos caches selon la suggestion de @ Fred-Kleuver peut aider, mais je n’ai pas fait toutes les étapes isolément, je ne suis donc pas sûr.
Ceci est courant selon VS 2015 CTP 6, en utilisant les versions bêta 4, pas les quotidiens.
Allez au gestionnaire de paquets Nuget et téléchargez l’adaptateur Nunit comme suit.
La solution dans mon cas consistait simplement à installer l'extension NUnit 3 Test Adapter dans mon Visual Studio 2015.
Il suffit de redémarrer Visual Studio et dans Test Explorer faire "Run All" ... Tous mes tests sont alors découverts.
J'avais le même pronlem mais le dossier "% TEMP%\VisualStudioTestExplorerExtensions" n'existait pas sur ma machine, j'ai donc eu l'idée de le créer et cela fonctionne. L'explorateur de tests est maintenant en mesure d'afficher tous mes tests .. Merci.
Dans mon cas (Visual Studio Enterprise 2015 14.0.25425.01, mise à jour 3, Resharper 2016.2), je devais faire une solution clean à partir du menu Générer. En reconstruisant la solution, l'explorateur de tests se "réveille" et retrouve tous les tests.
Cela n’aidera probablement pas la plupart des gens, mais une personne inexpérimentée au test unitaire avait écrit une méthode de test renvoyant bool au lieu de void:
[TestMethod]
public bool TestSomething()
Changer le type de retour en void a résolu le problème.
Dans mon cas, MSTest sous VS 2015 ignorait les tests avec des noms de test (méthode) supérieurs à 174 caractères. En raccourcissant le nom, le test était visible. Cela a été déterminé par devinettes et vérifications en manipulant le nom du test.
Dans mon cas, le problème était "entre la chaise et le clavier". J'étais passé à une configuration dans Configuration Manager qui n'incluait pas mes projets de test d'unité lors de la construction. Le retour à une configuration (par exemple, Debug) incluant tous les projets a résolu le problème.
Vérifiez que vous avezxunit.runner.visualstudiopackage dans votre projet test packages.config et que celui-ci a été correctement restauré.
Je sais que ce n'était pas le cas de la question initiale, mais cela pourrait faire gagner du temps à quelqu'un comme moi.
Je voudrais juste ajouter que j'ai trouvé une solution totalement différente de celles mentionnées ci-dessus.
J'avais déclaré ma classe de test comme ci-dessous:
[TestClass]
class ClassificationTests
{
//unit tests
}
Dès que j'ai ajouté le modificateur public à la classe, cela a fonctionné comme prévu!
Si vous ciblez .NET Standard ou .NET Core, vous devez utiliser le package NuGet pour NUnit Test Adapter et pas l'extension.
Il est recommandé d'installer l'adaptateur à partir de NuGet si vous testez des projets .NET Core ou .NET Standard. L'adaptateur VSIX ne prend pas et ne prendra pas en charge .NET Core car les packages VSIX ne peuvent pas cibler plusieurs plates-formes.
Source: NUnit GitHub Wiki
.
Vérifiez également la FAQ à cet endroit:
Mes tests ne s'affichent pas dans Visual Studio 2017?
- Utilisez-vous le package NuGet?
- Utilisez-vous la version 3.8.0 ou une version plus récente du package NuGet?
- Est-ce que vos tests ciblent .NET Core ou le .NET Framework complet? (voir au dessus)
- Avez-vous ajouté une référence de package à Microsoft.NET.Test.Sdk?
- Avez-vous redémarré Visual Studio? C'est encore un peu tempéré.
Source: NUnit GitHub Wiki
D'une manière ou d'une autre, mon projet était configuré pour être compilé en tant que Bibliothèque statique (.lib) . Après avoir changé cela en un Dynamic Library (.dll) , les tests ont été découverts correctement par Visual Studio 2012.
My Unit Test Project ->
Properties ->
Configuration Properties ->
General ->
Configuration Type
J'ai aussi été mordu par cette merveilleuse petite fonctionnalité et rien de ce qui est décrit ici n'a fonctionné pour moi. Ce n'est que lorsque j'ai vérifié deux fois la sortie de la construction et constaté que les projets pertinents n'étaient pas en cours de construction. Une visite au responsable de la configuration a confirmé mes soupçons.
Visual Studio 2015 m'avait permis d'ajouter de nouveaux projets, mais avait décidé que cela ne valait pas la peine de les construire. Une fois que j'ai ajouté les projets à la construction, il a commencé à bien jouer.
La suppression du fichier\AppData\Local\Microsoft\VisualStudio\14.0\1033\SpecificFold erCache.xml a résolu le problème pour moi.
Il était si facile pour moi de résoudre le problème de la manière suivante:
- Sélectionnez votre projet de test unitaire
- Cliquez sur le bouton 'Afficher tous les fichiers' dans l'Explorateur de solutions. De nouveaux fichiers temporaires apparaissent dans l'arborescence de l'Explorateur de solutions dans 'obj\x86\Debug'.
- Supprimez ces fichiers temporaires et reconstruisez le projet.
- Retenté pour exécuter des tests et a travaillé!.
Je l'ai résolu en changeant X64 en:
Passer pour partager ma solution. J'étais sous Windows 10, Visual Studio 2015, NUnit 3.5, NUnit Test Adapter 3.6 (via NuGet, et non l'extension VISX) et aucun de mes tests n'a été découvert. Mon problème était que dans le projet Tests de ma solution, un raccourci vers mon dossier "Documents" avait été créé dans le dossier du projet. J'imagine que l'adaptateur de test voyait le raccourci et commençait à raccrocher en essayant de comprendre quoi en faire, ce qui entraînait l'échec de l'affichage des tests unitaires.
Cela m'est arrivé parce que mon projet de test contenait un app.config. Il a été automatiquement ajouté par les packages NuGet pour la redirection de l'assemblage, mais mes tests semblaient bien fonctionner sans cela.
Voir: https://developercommunity.visualstudio.com/comments/42858/view.html .
Nous avons eu le même problème. Nous avons une grande solution VS 2015 avec plusieurs projets C # et encore plus de projets de test.
La découverte de test de Resharper a bien fonctionné, mais VS Test Explorer a échoué lamentablement.
Il s'avère que les projets n'avaient pas la même version de MsTest TestFramework et TestAdapter, et qu'ils utilisaient parfois NuGets et d'autres fois de bonnes références anciennes, et cela n'est apparemment pas pris en charge (tant pour un IDE aussi coûteux).
La suppression de toutes les références Microsoft.VisualStudio.Test * puis l'ajout/la mise à jour des deux MSTest NuGets a résolu le problème.
J'ai résolu ce problème en réalisant que le Target Framework de mon projet test était différent du projet à tester. Oui, j'ai causé ce problème en changeant le cadre cible par défaut (Projet> Propriétés> Application), mais je n'ai pas réussi à le faire pour le projet test créé plusieurs semaines plus tard. Cette incompatibilité n'a pas provoqué d'erreur de compilation, mais un avertissement a été généré dans la fenêtre Error List. Une fois que j'ai sélectionné l'option d'affichage des avertissements, la solution était évidente.
Après avoir passé 2 jours ... rien de ce qui précède n'a fonctionné pour moi. La seule "solution" était: Accédez aux propriétés du projet -> Onglet Construire. Cliquez ensuite sur le bouton Avancé dans le coin inférieur droit du volet. Remplacez "Informations de débogage" par "Complet" et cliquez sur OK.
Voici les captures d'écran: 
Désactiver le service Windows Defender. La désactivation immédiate de cette option a entraîné l'affichage de tous mes tests unitaires dans Test Explorer.
Assurez-vous que votre classe avec l'attribut [TestClass] est public et non private .
J'ai eu le même problème. Le modèle de test unitaire de Visual Studio 2015 (Update 3) génère une classe avec la propriété TestContext définie comme suit:
private TestContext testContextInstance;
/// <summary>
///Gets or sets the test context which provides
///information about and functionality for the current test run.
///</summary>
public TestContext TestContext
{
get
{
return testContextInstance;
}
set
{
testContextInstance = value;
}
}
Après le changer pour un champ public (ungly), le testeur peut découvrir le test.
public TestContext TestContext;
Un comportement très étrange, mais c'était la cause du problème dans mon cas.
J'ai eu le même problème. Je viens de nettoyer et de reconstruire le projet et j'ai pu voir les tests manquants.
Dans le volet Sortie VS (basculé vers la vue Test), il y avait cette erreur:
Impossible de charger le fichier ou l'assembly 'XXX.UnitTest, version = 9.4.0.0, Culture = neutre, PublicKeyToken = 14345dd3754e3918' ou l'une de ses dépendances. La validation du nom fort a échoué. (Exception de HRESULT: 0x8013141A)
Dans les paramètres du projet test, sous l'onglet Signature, quelqu'un avait coché la case "Signer l'assemblage". En décochant cela et en construisant, les tests sont apparus.
Un collègue a également résolu le même problème en ajoutant des clés de cette publication au registre:
Je voudrais ajouter une autre raison pour laquelle les tests peuvent ne pas être trouvés, dans mon cas, il s'agissait de tests unitaires C++ qui n'ont pas été trouvés.
Dans mon cas, aucun test n'a été trouvé pour un projet particulier car son répertoire de sortie ne figurait pas dans le répertoire du projet. Cette modification a permis de s'assurer que les tests ont été trouvés.
Ce sujet est quelque peu obsolète, mais ma solution au statut de test manquant dans VS2015:
L'état de la tâche n'apparaît que sur la configuration de construction Debug. Bien entendu, cela rend également impossible le débogage de votre test via le test-Explorer.
La seule chose qui a fonctionné pour moi a été: Supprimer C:\Utilisateurs (votre nom d'utilisateur)\AppData\Local\Temp
D’autres suggestions sont généralement valables, mais pour une raison quelconque, si VS ne prend pas vos modifications en compte et aboie dans votre sortie, il ne peut pas détecter les tests, le nettoyage de ce répertoire peut faire l'affaire. soyez juste "un jour" vous démarrez et aucune de vos solutions ne fonctionnera plus, alors que "hier" tout a bien fonctionné.
Je me débattais avec le même problème pour le framework VSTest et mes tests unitaires natifs.
Donc, après avoir fait tout ce que vous avez mentionné précédemment, j'ai supprimé chaque occurrence de symbole '#' dans le chemin de répertoire de ma solution. Cela fonctionne réellement.
Je le laisse ici pour les googleurs qui trouveront cette question à l'avenir.
Assurez-vous que vos méthodes de test n'ont pas de paramètres. Ceci est une autre manière que votre test ne se présentera pas.
Pas d'erreurs ou d'avertissements.
J'ai commis l'erreur de créer des méthodes asynchrones mais de retourner à vide.
Modifié: public async void Test()
À: public async Task Test()
Si vous travaillez avec plusieurs fichiers App ou Web.Config. par exemple:
Il est probable que vous utilisiez une configuration qui est RELEASE MODE et qui supprimera le paramètre du mode Debug de la configuration:
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
Modifiez la configuration en une configuration qui ne supprime pas DEBUG MODE.