Visual Studio 2015 ou 2017 ne découvre pas les tests unitaires

165

EDIT 2016-10-19:

La question initiale concernait un problème spécifique à VS2015 CTP6 avec le lanceur de test XUnit. Il ressort clairement des réponses qu'il existe un problème beaucoup plus large avec la découverte des 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 avérées utiles pour mieux comprendre les subtilités du testeur VS. J'apprécie que les gens partagent toujours leurs solutions!


Question originale 10/04/2015:

Depuis hier, mon explorateur de tests Visual Studio ne découvrira les tests pour aucun de mes projets. Il n'affiche 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 lorsque je clique avec le bouton droit sur une méthode de test et que je sélectionne «Exécuter les tests», j'obtiens ce qui suit dans ma 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, build 10041. La version .NET Framework ne semble pas avoir d'importance - cela se produit sur 4.0, 4.5.2et 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.0
  • xunit v2.1.0-beta1-build2945 avec xunit.runner.visualstudio v2.1.0-beta1-build1051
  • NUnit v2.6.4 avec NUnitTestAdapter v2.0.0

J'ai trouvé un problème sur GitHub (xunit) qui semblait être similaire: Impossible d'obtenir les tests découverts # 295 , avec ce commentaire de l'équipe xunit:

Sachez que Visual Studio 2015 CTP 5 a été signalé comme étant interrompu par de nombreuses personnes ayant des tests unitaires en général (pas seulement xUnit.net), alors ne vous attendez pas à ce que cela fonctionne.

Assurez-vous également d'avoir nettoyé le cache d'exécution de Visual Studio. S'il est corrompu, Visual Studio se comportera de manière permanente jusqu'à ce qu'il soit supprimé. Pour vider le cache, arrêtez toutes les instances de Visual Studio, puis supprimez le dossier% TEMP% \ VisualStudioTestExplorerExtensions (honnêtement, cela ne ferait probablement pas de mal de supprimer tout ce qui peut être supprimé dans% TEMP%).

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 fait capable de découvrir certains tests. Cela ne fonctionne que pour les tests VS et NUnit, pas pour xunit.

Il doit y avoir une sorte de dossier temporaire ou de cache que je dois effacer, mais je sais que Visual Studio en a beaucoup et que tous ne peuvent pas être supprimés sans effets secondaires indésirables.

Fred Kleuver
la source
3
Je suis tellement content d'avoir trébuché dessus, cela me rappelle pourquoi j'utilise un testeur tiers (dans mon cas ncrunch). J'ai abandonné mstest il y a longtemps pour des raisons similaires. Bien sûr, ce n'est pas une solution si vous êtes coincé avec mstest ...
Abel
en relation: stackoverflow.com/questions/35103781/…
Ruben Bartelink
avec VS 2017, assez incroyablement, un nettoyage de mes dossiers liés à temp et localappdata VS2017, une solution close + reload + clean et un redémarrage de Windows n'ont pas aidé. Cependant, étonnamment, un projet simlpe "déchargement - rechargement" sur un seul de mes projets de test a aidé la découverte de test à s'arrêter. Je n'utilise pas de package de test unitaire tiers.
Pac0
Pour certaines personnes, cela pourrait être intéressant ou plus pertinent (je ne pense pas que je devrais l'ajouter comme réponse): Aucune source disponible dans l'Explorateur de tests - github.com/Microsoft/testfx/issues/274
hB0
Cela pourrait être un correctif pour quelqu'un stackoverflow.com/a/58019304/1566372
Rady

Réponses:

154

À ma grande surprise, la suppression des fichiers temporaires situés dans le %TEMP%répertoire 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 naviguer vers le dossier temporaire en le mettant dans le %temp%menu Démarrer, ou lancer "File Explorer" et entrer %temp%dans la barre d'adresse.

RobM
la source
30
Ou vous tapez simplement %TEMP%dans le menu Démarrer Exécuter et il trouve votre dossier temporaire pour vous sans que vous deviniez quelle est la valeur de temp.
Warren P
65
@ ZéCarlos Toute application qui stocke des données importantes dans l' %TEMP%annuaire mérite de cesser de fonctionner.
Mark Pattison
25
ce n'est pas un embarras pour vous, c'est un échec total de Microsoft que vous deviez prendre des mesures aussi ridicules pour maintenir un IDE de plus de 1000 USD en fonctionnement.
MushyPeas
8
A également travaillé pour moi dans VS2017!
Lorentz Vedeler
6
Si vous êtes préoccupé par la suppression de tout le répertoire temporaire, seule la suppression du sous-répertoire Temp \ VisualStudioTestExplorerExtensions semble résoudre le problème.
Mike Walsh
90

Il se peut que votre code soit compilé avec x64, donc devez activer l'architecture de processeur par défaut en tant que X64.

Test > Test Settings > Default Processor Architecture > X64
Dac Toan Ho
la source
3
Cela m'a mordu à plusieurs reprises. Même après toutes ces années, je ne peux toujours pas penser à une bonne raison pour laquelle, par défaut, les paramètres de test ne sont pas sélectionnés pour correspondre automatiquement à la configuration de construction actuelle du projet. Cela me semble une configuration en double inutile.
Neutrino
1
La mise à jour Windows et / ou la mise à jour VS modifient l'architecture par défaut sans vous le dire .... aaargh
rupweb
Et 4 ans plus tard, c'est toujours utile. Merci
Oscar
67
  • Vérifiez si NUnit Test Adapter 2/3 est installé dans VisualStudio.
    (Tools>Extensions and Updates )

  • Assurez-vous que l'architecture de processeur appropriée est choisie:
    (Test>Test Settings>Default Processor Architecture)

MichiBack
la source
2
C'est ce qui a finalement fonctionné pour moi. Après avoir tout essayé.
BradStell
Vous donne l'impression d'être un imbécile de fouiller d'abord dans les dossiers temporaires lorsque l'extension n'est même pas installée. Merci d'avoir publié ceci.
NightOwl888
2
Vérifiez également si vous utilisez la bonne extension. Il existe un autre pour NUnit 2.x et NUnit 3.x.
pmbanka
1
Lorsque vous ciblez .NET Standard, vous devez en fait installer le package NuGet NUnit Test Adapter au lieu d'une extension VSIX. github.com/nunit/docs/wiki/.NET-Core-and-.NET-Standard
m93a
Essayez d'obtenir NUnit3TestAdapter à partir de nuget, au lieu de VSIX. C'est la meilleure approche
Ravella
33

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 la suppression du cache / dossier temporaire / fichiers pertinents pour moi. 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 au préalable et c'est probablement une bonne idée de redémarrer par la suite.

La suppression du dossier TEMP peut ne pas être nécessaire et peut même être indésirable dans certains cas, je vous recommande donc d'essayer sans effacer d'abord le dossier TEMP. Omettez simplement le "$env:TEMP".

Réponse originale 2015-04-12

Le problème a été «résolu» après un nettoyage en profondeur des dossiers temporaires / cache liés à Visual Studio.

Comme je n'ai pas eu le temps de tout parcourir un par un puis de tester entre les deux, je ne sais malheureusement pas lequel a réellement causé le problème.

Voici les étapes exactes que j'ai prises:

  1. Visual Studio fermé
  2. CCleaner utilisé pour effacer les tempfichiers / dossiers du système et du navigateur
  3. Effacer / supprimer 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
Fred Kleuver
la source
Merci, travaillé pour moi après avoir effacé les dossiers Microsoft \ VisualStudio \ 14.0 \ et Microsoft \ VisualStudio Services \ 6.0 \ Cache que vous décrivez.
Niels van Reijmersdal
Vous voulez sûrement dire \Microsoft\VisualStudio\14.0\ImageLibrary\ImageLibrary.cache?
Mateen Ulhaq
2
J'ai tout supprimé de% TEMP% et cela ne fonctionne pas, mais quand j'ai lu le répertoire 'VisualStudioTestExplorerExtensions' (vide) tout fonctionne parfaitement :-) (Il y a une réponse avec cette solution en bas à la journée actuelle)
nilphilus
Je veux confirmer que cette solution fonctionne pour moi avec VS2015 Update 3 et Resharper 10. Mais vous devez redémarrer pour voir le miracle
Quoc Nguyen
1
J'ai supprimé un seul fichier \ AppData \ Local \ Microsoft \ VisualStudio \ 14.0 \ 1033 \ SpecificFolderCache.xml il hepls
Serhii Kuzmychov
21

L'une des raisons de ce problème est que votre classe de test n'est pas publique. MSTest ne découvre que les tests des classes publiques.

AfshinS
la source
1
Bien que ce ne soit pas correct à 100% et que ma classe non publique fonctionne correctement, à un moment donné, son test unitaire a cessé de fonctionner. Lorsque j'ai changé la classe de test unitaire en public, elle a recommencé à fonctionner. Allez comprendre!
SashaArz
Cela a résolu le problème pour moi. Par défaut, Visual Studio ajoute des classes de test sans le mot clé public, et il ne les verra pas tant que je ne les rendrai pas publiques.
Marc Fearby
13

Dans Visual Studio 2015 (mise à jour 3), si vous souhaitez attacher les tests dans l'explorateur de tests, vous devez installer l' adaptateur de test NUnit.Téléchargez l'adaptateur à partir de l' onglet Outils-> Extension et mises à jour-> En ligne (vous devez rechercher l'adaptateur ) -> Télécharger . En redémarrant Visual Studio, vous pouvez voir la modification de l'infrastructure de test.

Pankti Shah
la source
2
En suivant vos instructions, j'ai cherché "nunit" et j'ai trouvé "NUnit 3 Test Adapter" qui, après "Télécharger" (installer), a résolu mon problème. La recherche sur Internet pour ce problème trouve un autre article SO sur le lien
Adam Cox
C'est mieux que le gestionnaire de paquets Nuget dans certains scénarios car il ne change pas les fichiers de configuration
GY_
1
@GY_ mais lorsque vous ciblez .NET Core ou Standard, vous avez réellement besoin du package NuGet, vérifiez ma réponse ci-dessous: stackoverflow.com/a/47460221/1137334
m93a
Vous sauvez ma vie! Merci, j'ai essayé tant de solutions et cela n'a pas fonctionné. Le mien était l'adaptateur de test Google.
Erman
9

Je n'ai pas de réponse complète à cela, mais j'ai déterminé certaines choses en jouant avec un projet de test:

  1. Le xunit.runner.aspnet : 2.0.0-aspnet-beta4qui semble faire partie de la version bêta4 officielle aspnet5 ne fonctionne pas dans Visual Studio.
  2. Au lieu de cela, l'utilisation "xunit": "2.1.0-*"et les "xunit-runner.dnx": "2.1.0-*"packages fonctionnent dans Visual Studio.
  3. Pour que VS découvre 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.
  4. Si votre fenêtre de l'Explorateur de tests finit toujours par être vide, SUPPRIMEZ la commande «test» de votre projet, puis recréez la solution, puis ajoutez la commande «test» au project.json.
  5. Effacer tous vos caches selon la suggestion de @ Fred-Kleuver peut aider, mais je n'ai pas fait toutes les étapes isolément, donc je ne suis pas sûr.

Ceci est actuel selon VS 2015 CTP 6, en utilisant les versions beta4, pas les quotidiens.

Cerise avi
la source
1
D'accord, j'ai confirmé (en demandant à un collègue de l'essayer) que le correctif ci-dessus ne nécessite aucun effacement des caches ou des fichiers temporaires.
Avi Cherry
Ci-dessus dit "Au lieu de cela, en utilisant" xunit ":" 2.1.0- "et" xunit-runner.dnx ":" 2.1.0- "les packages fonctionnent dans Visual Studio.". Cela fonctionne, merci!
Gillardo
Btw, comme suivi, tout semble bien fonctionner maintenant dans VS 2015 à partir des versions actuelles. Pas de soucis requis pour faire apparaître de nouveaux tests ou quoi que ce soit.
Avi Cherry
1
Enfin, il existe maintenant un guide approprié de MS sur exactement quelles versions de xunit utiliser avec quelles versions de DNX, ici: xunit.github.io/docs/getting-started-dnx.html
Avi Cherry
9

J'ai eu une instance où certains tests ne seraient pas repris parce que je les avais faits asynccomme suit:

public async void This_IsMy_UnitTest()

Le problème était que j'avais oublié de les faire revenir a Tasket pas voidquand j'ai fait le basculement. On pourrait penser que cela provoquerait une erreur ou un test échoué, mais non. Les tests unitaires de cette classe ont été totalement ignorés et ont agi comme s'ils n'existaient pas.

Ce n'est pas après environ 3 nettoyages et builds + redémarrage VS.NETque j'ai vu le test s'exécuter et échouer, indiquant que j'ai oublié d'ajouter le Tasktype de retour:

public async Task This_IsMy_UnitTest()

Après la mise à jour, les tests unitaires ont été trouvés et ont fonctionné correctement. Cela peut être un cas limite, mais avoir des asynctests pour utiliser awaitdedans mais ne pas avoir la signature correcte peut causer ce même problème et ce n'est pas la première fois que je fais cela.

atconway
la source
Résolu le problème pour moi!
Aimal Khan
8

Accédez au gestionnaire de packages Nuget et téléchargez Nunit Adapter comme suit.

entrez la description de l'image ici

Debendra Dash
la source
Merci, dans mon cas, j'avais NUnitTestAdapter au lieu de NUnit3TestAdapter. Cela a résolu mon problème.
pixel
L'ajout du package nuget NUnit3TestAdapter à une solution ou à un projet ne résoudrait pas le problème pour toutes les autres solutions en général, mais uniquement pour celles auxquelles il a été ajouté. Afin de le faire généralement pour toutes les solutions / projets, ajoutez l'extension NUnit 3 Test Adapter à votre studio visuel comme expliqué à stackoverflow.com/a/45748818/1300390
Umar T.
6

J'avais le même pronlem mais le dossier "% TEMP% \ VisualStudioTestExplorerExtensions" n'existait pas sur ma machine alors en lisant les messages j'ai eu l'idée de le créer et ça marche. L'explorateur de tests est maintenant capable d'afficher tous mes tests. Merci.

Vinci
la source
6

Redémarrez simplement Visual Studio et dans l'Explorateur de tests, faites "Tout exécuter" ... Tous mes tests sont alors découverts.

Lukyer
la source
1
J'ai également remarqué que la fermeture de l'Explorateur de tests, la réouverture et le choix de Tout exécuter fonctionne également. Je ne sais pas encore si cela fonctionne toujours mais cela a fonctionné cette fois.
Rich
5

Dans mon cas (Visual Studio Enterprise 2015 14.0.25425.01 Update 3, Resharper 2016.2), j'avais juste besoin de faire une solution propre à partir du menu Générer. La reconstruction de la solution provoque alors le «réveil» de l'explorateur de tests et la recherche de tous les tests.

sammy34
la source
5

La solution dans mon cas était simplement d'installer l' extension NUnit 3 Test Adapter sur mon Visual Studio 2015.

'Extensions et mises à jour' est présent sous le meue 'Outils'

Umar T.
la source
Comment votre réponse ajoute-t-elle de la valeur à la question? Les avez-vous lus? Il y a déjà deux réponses qui recommandent exactement la même solution: stackoverflow.com/a/41364951/6305294 , stackoverflow.com/a/35043380/6305294
Alex
2
Eh bien, j'ai lu le premier (c'est-à-dire stackoverflow.com/a/41364951/6305294) mais c'est différent de ma réponse car cela suggère d'ajouter le package nuget NUnit Adapter à une solution ou à un projet, ce qui ne résoudrait pas le problème. problème pour toutes les autres solutions en général. En ce qui concerne le deuxième, je dois admettre que j'ai manqué de le voir. Peut-être que l'ajout d'une capture d'écran permet à l'œil de l'attraper lorsqu'il y a deux nombreuses réponses à une question
Umar T.
4

Dans mon cas, le problème était "entre la chaise et le clavier". J'étais passé à une configuration dans le gestionnaire de configuration qui n'incluait pas mes projets de test unitaire lors de la construction. Le retour à une configuration (par exemple Debug) qui inclut tous les projets a résolu le problème.

AndyZez
la source
4

Dans mon cas, MSTest sous VS 2015 ignorait les tests avec des noms de test (c'est-à-dire de méthode) de plus de 174 caractères. Raccourcir le nom a permis au test d'être visible. Cela a été déterminé par deviner et vérifier en manipulant le nom du test.

Kenneth K.
la source
4

Cela n'aidera probablement pas la plupart des gens, mais quelqu'un inexpérimenté dans les tests unitaires avait écrit une méthode de test qui retournait boolau lieu de void:

[TestMethod]
public bool TestSomething()

Modification du type de retour pour voidrésoudre le problème.

Sam
la source
Encore intéressant de savoir que retourner un type empêche la découverte de test, je ne le savais pas.
Fred Kleuver
3

Assurez-vous que vous avez un xunit.runner.visualstudiopackage dans votre projet de test packages.config et qui a également é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.

pvasek
la source
3

Je voudrais juste ajouter que j'ai trouvé une solution totalement différente de celles 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 publicmodificateur à la classe, cela a fonctionné comme prévu!

Persistance
la source
2

Si vous ciblez .NET Standard ou .NET Core, vous devez utiliser le package NuGet pour NUnit Test Adapter et non 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: Wiki NUnit GitHub

.

Consultez également la FAQ ici:

Mes tests ne s'affichent pas dans Visual Studio 2017?

  • Utilisez-vous le package NuGet?
  • Utilisez-vous la version 3.8.0 ou plus récente du package NuGet?
  • Vos tests ciblent-ils .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 capricieux.

Source: Wiki NUnit GitHub

m93a
la source
1

J'ai eu le même problème. Je viens de nettoyer et reconstruire le projet et j'ai pu voir les tests qui manquaient.

Eric
la source
1

Je passe pour partager ma solution. J'étais sous Windows 10, Visual Studio 2015, NUnit 3.5, NUnit Test Adapter 3.6 (via NuGet, pas 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 se raccrochait en essayant de savoir quoi en faire, entraînant l'échec de l'affichage des tests unitaires.

Thomas Parikka
la source
1

La suppression du fichier \ AppData \ Local \ Microsoft \ VisualStudio \ 14.0 \ 1033 \ SpecificFold‌ erCache.xml a résolu le problème pour moi.

der_chirurg
la source
1

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 build de débogage. Bien sûr, cela rend également impossible le débogage de votre test via l'explorateur de tests.

pehur
la source
1

J'ai également été mordu par cette merveilleuse petite fonctionnalité et rien de décrit ici n'a fonctionné pour moi. Ce n'est que lorsque j'ai revérifié le résultat de la construction et que j'ai remarqué que les projets pertinents n'étaient pas en cours de construction. Une visite au gestionnaire de configuration a confirmé mes soupçons.

Visual Studio 2015 m'avait heureusement permis d'ajouter de nouveaux projets, mais a décidé que cela ne valait pas la peine de les construire. Une fois que j'ai ajouté les projets à la construction, la lecture a bien commencé.

Robbie Dee
la source
1

Je l'ai résolu en changeant X64 en: Faites un clic droit sur le projet -> Propriétés -> Build -> Platform target -> Any CPU

Pouyan Sepahvand
la source
1

D'une manière ou d'une autre, mon projet a été configuré pour se compiler en tant que bibliothèque statique (.lib) . Après avoir changé cela en une bibliothèque dynamique (.dll) , les tests ont été détectés correctement par Visual Studio 2012.

My Unit Test Project ->
Properties ->
Configuration Properties ->
General ->
Configuration Type
Maate
la source
1

Il était si facile pour moi de résoudre le problème comme suit:

  • Sélectionnez votre projet de test unitaire
  • Cliquez sur le bouton «Afficher tous les fichiers» dans l'Explorateur de solutions et de nouveaux fichiers temporaires sont apparus dans l'arborescence de fichiers de l'Explorateur de solutions dans «obj \ x86 \ Debug».
  • Supprimez ces fichiers temporaires et reconstruisez le projet.
  • Réessayé d'exécuter des tests et a travaillé !.
mggSoft
la source
1

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 très bien fonctionné, mais VS Test Explorer a lamentablement échoué.

Il s'avère que les projets n'avaient pas la même version de MsTest TestFramework et TestAdapter, et que parfois ils utilisaient NuGets et d'autres fois de bonnes vieilles références, et cela n'est apparemment pas pris en charge (tant pour un IDE aussi cher).

La suppression de toutes les références Microsoft.VisualStudio.Test * , puis l' ajout / la mise à jour des deux NuGets MSTest ont résolu le problème.

TommyD
la source
1

J'ai résolu ce problème en réalisant que le cadre cible de mon projet de test était différent du projet en cours de test. Oui, j'ai causé ce problème en modifiant le cadre cible par défaut (Projet> Propriétés> Application), mais j'ai échoué à cela pour le projet de test, qui a été créé plusieurs semaines plus tard. La non-concordance n'a pas provoqué d'erreur du compilateur, mais elle a entraîné un avertissement dans la fenêtre Liste d'erreurs . Une fois que j'ai sélectionné l'option d'affichage des avertissements, la solution était évidente.

JerryM
la source