Je suis en train de mettre à niveau notre solution existante vers .Net 4.6.1 et je n'ai pas pu faire exécuter nos tests unitaires pendant la construction d'un serveur. Localement, ils fonctionnent comme prévu et le retour de la version du framework vers .Net 4.5.1 les fait fonctionner à nouveau sur le serveur.
Je reçois l'erreur suivante:
Aucun test trouvé. Assurez-vous que les découvreurs et exécuteurs de test installés, les paramètres de version de la plate-forme et du framework sont appropriés et réessayez.
J'ai reproduit le problème dans une configuration plus simple:
- Solution avec un seul projet de test unitaire C # avec deux tests (un échec, un réussissant).
- Définition de build XAML à l'aide du modèle par défaut (TfvcTemplate.12.xaml)
- TFS 2015 Update 1 XAML build server avec Visual Studio Enterprise 2015 Update 1 installé (ont six serveurs similaires et produisent tous le même résultat)
unit-testing
tfs
build
tfs-2015
Tore Østergaard
la source
la source
Réponses:
Vous pouvez essayer de changer votre architecture de processeur par défaut dans votre paramètre de test de X86 à X64. Dans mon cas, c'était le problème.
Cela se produit si la cible de plate-forme de votre projet en cours de test est définie sur
x64
.la source
Ma version ne trouvait pas non plus les tests. Ma configuration et ma solution pour trouver les tests sont les suivantes.
J'utilise VSTS (Visual Studio Team Services) et j'ai une build qui est configurée pour actualiser les packages NUGET sur chaque build. J'utilise NUnit et j'ai constaté que l'exécution de la commande NUGET suivante (à partir de la console du gestionnaire de packages dans Visual Studio) pour ajouter la bibliothèque NUnitTestAdapter à mon projet de test et la vérification dans packages.config ont fait exécuter les tests dans ma version VSTS.
Comme Maurice le mentionne dans le commentaire de cet article pour NUnit3, utilisez le package NUGET suivant (recherchez d'autres utils sur le lien. Ex: dotnet CLI et Paket CLI)
J'espère que cela t'aides.
la source
Dans mon cas, je devais:
1) Convertir le projet de test en netcore 2.0 (était netstandard 2.0)
2) Ajouter un paquet nuget
xunit.runner.visualstudio
Référence: http://www.neekgreen.com/2017/11/20/xunit-no-test-is-available/
la source
J'ai eu cette erreur et j'ai pu la résoudre.
la source
J'utilise MSTest. Pour moi, c'était une version incorrecte et il manquait un autre package dépendant -
1) Mon dossier de package contient uniquement le package MSTest.TestFramework.1.2.1. Dans mon fichier de projet (.csproj), la référence dans le nom de la cible était le package MSTest.TestAdapter.1.2.0 qui n'était pas présent dans le dossier du package. Mon packages.config fait également référence à MSTest.TestFramework.1.2.0.
2) J'ai donc installé MSTest.TestAdapter.1.2.0 à partir du gestionnaire de packages nuget et aligné la version MSTest.TestFramework sur 1.2.0 dans le fichier de projet et de package. Enfin, j'ajoute Microsoft.VisualStudio.TestPlatform.TestFramework et Microsoft.VisualStudio.TestPlatform.TestFramework.Extensions dans la référence.
Ensuite, tout allait bien. J'espère que cela aidera quelqu'un.
la source
Ce problème réapparaît pour Visual Studio 2017. Très probablement un autre bug mais le même résultat.
Une solution de contournement qui semble fonctionner consiste à désinstaller le débogueur distant Microsoft Visual Studio 2017 de l'ordinateur concerné.
la source
la source
J'ai rencontré le même problème dans VSTS avec .Net 4.6.2. Si vous voyez cela à partir de la sortie de votre console VSTS, la solution de contournement fournie par @Sushil fonctionne toujours dans VSTS et est nécessaire. Malheureusement, la tâche "Test Assemblies" fournie par Microsoft réussit, donc vous ne savez même pas vraiment qu'il y a un problème à moins que vous ne vérifiiez la sortie et ne trouviez aucun de vos tests réellement exécuté!
la source
Si vous exécutez vos tests dans docker à l'aide de la construction à plusieurs étapes et que les tests ne sont pas trouvés. Assurez-vous de copier tous les fichiers non seulement les fichiers de projet comme ci-dessous la section Dockerfile.
la source
J'ai résolu ce problème dans le projet de test VS 2017 et 4.6.2 avec les étapes suivantes:
la source
Assurez-vous que le nuget «Microsoft.NET.Test.Sdk» est installé.
la source
Il s'agit d'un problème connu pour .Net 4.6 actuellement.
Voici une question similaire pour votre référence: Impossible d'exécuter les tests unitaires .Net 4.6 du serveur de build XAML TFS 2015
la source
Je fixe ce problème en réinstallant tous les tests liés paquets NuGet pour le projet:
Xunit
,Xunit.runner.vistualstudio
,Microsoft.Net.Test.Sdk
la source
J'obtenais un problème similaire et j'ai remarqué qu'un
app.config
fichier avait été ajouté à mon projet de test. La suppression de ce fichier de configuration l'a corrigé pour moi.la source
Je vais jeter ma solution sur le tas. Dans mon cas, j'ajoute quelques projets à une solution existante avec des projets de test pour eux. Nous utilisons MSTest. Un fichier UnitTest.testsettings précédent était activé sur la solution qui causait des problèmes de compatibilité.
Cliquer sur le fichier de paramètres a supprimé le contrôle et le test a réussi pour mes tests.
la source
Trouvé un moyen! Probablement pas le plus orthodoxe, mais cela m'a aidé à la hâte:
Je ne pense pas qu'il y ait quelque chose de particulier avec la version, mais sa mise à jour nettoie certainement toute référence mauvaise dans la solution / projet.
la source
C'est juste pour récapituler la solution proposée par @Sushil plus tôt.
Il s'agit d'un problème connu dans Team Foundation Server 2015 RTM + Update 1 et sera résolu dans la mise à jour 2, référence .
Il existe une solution de contournement décrite par @Sushil ici , qui comprend l'ajout d'un fichier .runsettings qui force le lanceur de test à un framework .Net plus ancien (veuillez noter que vous devez le spécifier via la boîte de dialogue "Ajouter / Modifier une exécution de test" en l'ajoutant directement dans l'éditeur de processus de construction sera ignoré).
la source
En utilisant .Net Core avec un pipeline de build dans TFS 2017, mon étape de test Visual Studio passait sans exécuter de tests. J'ai dû modifier l'étape "Options d'exécution avancées" -> "Autres options de la console" pour inclure:
(Ce champ contient également
/platform:x64
)la source
Dans Visual Studio 2017, je désinstalle et réinstalle simplement NUnitTestAdapter ou installe un nouveau package comme le package NUnitTestAdapter.WithFramework et le problème a disparu.
la source
J'ai eu cette erreur car ma classe de test unitaire n'était pas publique.
Ex:
class ClientTests
Erreur de sortie:
...\bin\Debug\Tests.dll] UTA001: TestClass attribute defined on non-public class ClientTests
Correction:
public class ClientTests
la source
J'ai le même problème. J'utilise Visual Studio 2017 Community Edition.
J'ai utilisé ces étapes pour découvrir avec succès tous mes cas de test et l'exécuter avec succès:
Allez d'abord dans Extensions et mises à jour, installez l'adaptateur de test NUnit3. Si vous l'avez déjà, activez-le.
Redémarrez votre Visual Studio 2017, il vous demandera automatiquement d'
installer votre extension, si une invite dit de terminer la tâche pour continuer l'
installation, cliquez simplement sur «Fin de tâche».
Après cela, reconstruisez votre projet de test et tous les cas de test seront désormais identifiés et vous pouvez maintenant commencer à exécuter vos cas de test.
la source
Dans mon cas, la réinstallation de l'adaptateur Nunit3, la suppression des dossiers temporaires, la modification de l'architecture et rien n'a fonctionné. C'est à cause du démon Resharper a causé le problème.
Cela résout les problèmes.
la source
Cette erreur peut se produire pour les tests asynchrones si vous avez le mauvais type de retour. Le type de retour doit être Task et non void.
la source
Après avoir ajouté TestAdapterPath dans le commandant, cela a fonctionné pour moi:
la source
Dans mon cas, les tests ont été découverts mais l'exécution a abouti à "Test non disponible ... " et le (in) célèbre: "Assurez-vous que le découvreur de tests et les exécuteurs sont enregistrés et que les paramètres de version de la plate-forme et du framework sont appropriés et réessayez."
l'erreur était indépendante de Visual Studio (testé à partir des outils CLI dotnet et du test UNit presque nu) et c'était uniquement lors du ciblage de .NET 4.7.1. L'application dotnetcore fonctionne très bien.
l'exécution de tests avec l'interface de ligne de commande Nuint3
nunit3-console.exe Tests.csproj
affiche également l'erreur:"Soit l'assemblage ne contient aucun test, soit le pilote de test approprié n'a pas été trouvé."
L'erreur était due au fait que l'adaptateur de test était introuvable sur un lecteur ou un partage réseau (mappé) et a été résolu en le copiant localement et en le réexécutant.
la source
si vous avez déjà installé un adaptateur de test dans le projet de test, essayez de le désinstaller du projet et de l'installer à nouveau dans le projet de test.
Ce correctif de base fonctionne pour moi.
la source
Essayez de courir
vstest.console.exe
avec--diag:diag.txt
et inspectez la sortie. Pour moi, c'était des échecs de chargement de DLL pour les adaptateurs de test de mon répertoire de travail:TpTrace Information: 0 : 14976, 1, 2020/03/10, 15:34:22.120, 57158093583, vstest.console.exe, AssemblyResolver.OnResolve: Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter: Failed to load assembly. Reason:System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Directory\Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
File name: 'file:///C:\Directory\Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.dll' ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
J'ai contourné ce problème en ajoutant
<loadFromRemoteSources enabled="true"/>
sous<runtime>
dans vstest.console.exe.configla source
J'utilise MSTest.
J'ai installé à partir de Nuget la dernière version de MSTest.TestFramework et remplacé OOB Supprimer les références à Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Puis installé à partir de neget la dernière version de Microsoft.
Cela m'a permis d'exécuter le test avec une commande:
Mais j'ai eu la même erreur. La cause première de l'erreur est que je n'ai pas spécifié d'adaptateur de test qui analyse l'assemblage et trouve des tests.
Solution:
Installez un package nuget "MSTest.TestAdapter"
Spécifiez un adaptateur de test à la fin d'une commande:
/TestAdapterPath:".\packages\MSTest.TestAdapter.2.1.2\build_common "
la source
Pour ceux qui sont confrontés au problème similaire .Voici la solution, veuillez installer SpecFlowPlusRunner.
J'ai essayé d'autres solutions telles que la réinstallation, la suppression du cache, etc. Mais la solution est en fait différente, nous devons installer SpecRun.SpecFlow2.3.0 pour visualstudio 2017.Cela a résolu le problème.
J'espère que cela aide tout le monde.
la source
J'ai rencontré le même problème lorsque j'ai essayé nUnit dans VS 2017 et ce n'est pas un projet principal. L'installation a
NUnit3TestAdapter
résolu le problème.la source