La méthode de test n'est pas concluante: le test n'a pas été exécuté. Erreur?
J'ai une classe de test et ci-dessous, j'ai posté un exemple de test de la classe de test
namespace AdminPortal.Tests.Controller_Test.Customer
{
[TestClass]
public class BusinessUnitControllerTests
{
private IBusinessUnitRepository _mockBusinessUnitRepository;
private BusinessUnitController _controller;
[TestInitialize]
public void TestInitialize()
{
_mockBusinessUnitRepository = MockRepository.GenerateMock<IBusinessUnitRepository>();
_controller = new BusinessUnitController(_mockBusinessUnitRepository);
}
[TestCleanup]
public void TestCleanup()
{
_mockBusinessUnitRepository = null;
_controller.Dispose();
_controller = null;
}
#region Index Action Tests
[TestMethod]
public void Index_Action_Calls_GetAllBusinessUnit()
{
_mockBusinessUnitRepository.Stub(x => x.GetAllBusinessUnit());
_controller.Index();
_mockBusinessUnitRepository.AssertWasCalled(x=>x.GetAllBusinessUnit());
}
}
}
Lorsque je lance le projet, l’écran suivant s’affiche 
J'ai vérifié les références et le projet de test a la référence au projet principal . Avez-vous une idée de la raison pour laquelle les tests ne sont pas en cours d'exécution ou ne sont pas concluants?
Éditer 1:
J'ai vu un article ici et modifié l'architecture de processeur par défaut de mon test en X64, mais cela ne fonctionne toujours pas.
C'était un problème de Resharper. Dans Options Resharper-> Outils-> MSTEST, j'ai décoché Utiliser Legacy Runner et maintenant cela fonctionne.
Juste au cas où aucune des options ci-dessus ne fonctionnerait pour quelqu'un, j'ai corrigé l'instance de cette erreur en remarquant une entrée corrompue dans mon App.Config en raison d'un paquet nuget manquant dans le projet test.
Pour moi, c'était plutôt frustrant, mais j'ai au moins trouvé une solution pour mon cas:
Si votre méthode de test est asynchrone, elle ne peut être annulée. Il DOIT retourner la tâche.
J'espère que ça aide quelqu'un :)
J'ai eu le même problème avec resharper et j'ai corrigé cette erreur en changeant une option:
Resharper => Options => Outils => Tests unitaires
Il me suffisait de décocher l'option "Assemblages de clichés instantanés testés"
J'avais ce problème, et il s'est avéré être le même que ce problème ici } _. _ { Cette réponse a résolu le problème pour moi } _.
- Décochez la case "Construire uniquement les projets de démarrage et les dépendances sur Exécuter" (Options -> Projets et solutions -> Construire et exécuter)
- Dans Configuration Manager, assurez-vous que "Construire" est coché dans le projet de démarrage et dans le projet test.
La deuxième fois que j'ai rencontré ce problème, c'était à cause d'une esperluette dans le chemin du fichier du projet où résident les tests. Cela fonctionne bien avec le testeur de ReSharper, mais pas avec le dotCover. Supprimez l'esperluette du chemin du fichier.
Ceci est un bug confirmé avec dotCover.
Pour moi, le simple nettoyage et la reconstruction de la solution ont résolu le problème.
Pour moi, le problème était un fichier XML corrupt NUnit/ReSharper settings (en raison d'une panne de courant inattendue).
Pour identifier l'erreur, j'ai lancé Visual Studio avec cette commande :
devenv.exe /ReSharper.LogFile C:\temp\resharper.log /ReSharper.LogLevel Verbose
L'examen du dossier a révélé l'exception suivante:
09:45:31.894 |W| UnitTestLaunch | System.ApplicationException: Error loading settings file
System.ApplicationException: Error loading settings file ---> System.Xml.XmlException: Root element is missing.
at System.Xml.XmlTextReaderImpl.Throw(Exception e)
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
at System.Xml.XmlDocument.Load(XmlReader reader)
at System.Xml.XmlDocument.Load(String filename)
at NUnit.Engine.Internal.SettingsStore.LoadSettings()
--- End of inner exception stack trace ---
at NUnit.Engine.Internal.SettingsStore.LoadSettings()
at NUnit.Engine.Services.SettingsService.StartService()
at NUnit.Engine.Services.ServiceManager.StartServices()
at NUnit.Engine.TestEngine.Initialize()
at NUnit.Engine.TestEngine.GetRunner(TestPackage package)
at JetBrains.ReSharper.UnitTestRunner.nUnit30.BuiltInNUnitRunner.<>c__DisplayClass1.<RunTests>b__0()
at JetBrains.ReSharper.UnitTestRunner.nUnit30.BuiltInNUnitRunner.WithExtensiveErrorHandling(IRemoteTaskServer server, Action action)
Notez que ceci est ET NON l'app.config du projet test!
A google rapide around identifia le fichier suivant comme étant le coupable:
%LOCALAPPDATA%\NUnit\Nunit30Settings.xml
Il existait, mais était vide. Le supprimer et redémarrer Visual Studio a résolu le problème.
(Utilisation de Visual Studio Professional 2017 v15.3.5 et de ReSharper 2017.2.1).
Je viens de résoudre ce problème aussi. Cependant, aucune des solutions de ce fil n'a fonctionné. Voici ce que j'ai fait ...
Puisque R # ne donnait aucun détail sur la raison de l'échec, j'ai décidé d'essayer le programme de test intégré VS2013. Il a eu exactement le même comportement où aucun des tests n’a été exécuté. Cependant, en regardant dans la fenêtre de sortie, j'ai finalement eu un message d'erreur:
Une exception s'est produite lors de l'appel de l'exécuteur 'executor: // mstestadapter/v1': La référence d'objet n'est pas définie sur une instance d'un objet.
Cela m'a amené à un autre thread sur SO avec une solution. Croyez-moi, je n'aurais JAMAIS deviné quel était le problème.
J'avais récemment apporté quelques modifications au fichier AssemblyInfo.cs lors de la création d'un package NuGet. L'un des changements consiste notamment à spécifier une valeur de culture en Assembly de "en".
J'ai changé ceci:
[Assembly: AssemblyCulture("")]
pour ça:
[Assembly: AssemblyCulture("en")]`.
C'était ça! C'est ce qui a inexplicablement brisé mes tests unitaires. Je ne comprends toujours pas pourquoi, cependant. Mais au moins les choses fonctionnent à nouveau. Après avoir annulé ce changement (c'est-à-dire redéfini la culture sur ""), mes tests ont recommencé.
J'espère que ça aide quelqu'un là-bas.
En ce qui me concerne, c’est une erreur que j’ai commise lors de la copie de la chaîne de connexion dans le fichier app.config .. Je l’avais placée dans le tag configSections!
Il m'a fallu un peu de temps pour réaliser que ... merci VS intellisense cependant .. ou était-ce resharper?
Dans mon cas, les méthodes [Test] étaient simplement private. La honte
Mon problème était que je n'avais installé que NUnit avec nuget. Je n'avais pas installé NUnit3TestAdapter, qui était également requis.
Install-Package NUnit3TestAdapter
J'ai eu un problème similaire. VS 2010, c # CLR 2 Nunit 2.5.7, il suffit de construire la solution> propre de VS pour résoudre ce problème
Dans mon cas, j'ai créé une méthode de test asynchrone qui a retourné void. Le renvoi de Task au lieu de void a résolu le problème.
Pour ceux qui rencontrent ce problème pour mon projet test .NET Core 2.0 dans la Visual Studio 2017 Community (v15.3 3). J'ai aussi eu ce bogue en utilisant JetBrains ReSharper Ultimate 2017.2 Build 109.0.20170824.131346 - il y a un bogue j'ai posté.
JetBrains a conseillé de créer un nouveau projet de test à partir de zéro pour le reproduire. Lorsque j’ai fait cela et que les tests fonctionnaient bien, j’ai trouvé la raison du problème:
- Supprimer ceci de votre fichier
*.csproj: Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c358}"
Quand j'ai fait cela - les tests ont bien fonctionné.
Dans mon cas, j'ai eu cette erreur à cause du mode 'Release' où la construction du projet UnitTests était simplement désactivée. Revenir en mode 'Debug' a corrigé le problème.
Il est vraiment étonnant que ReSharper ne puisse rien dire au cas où il ne pourrait pas trouver la bibliothèque UnitTests. Sérieusement, c'est dommage;)
J'espère que ça va aider quelqu'un
Avez-vous ajouté une dépendance DLL récemment? ... comme moi
Je viens de rencontrer le même problème et il était très exaspérant de ne rien savoir dans la fenêtre de sortie du test ou ailleurs.
La cause était extrêmement stupide: je venais d'ajouter la veille de la dépendance à un DLL externe supplémentaire dans un sous-projet, et l'application du projet principal était en effet construite et exécutée correctement après le changement. Mais mes tests unitaires sont dans un projet associé à l’application principale, ce qui explique également la dépendance vis-à-vis de ce sous-projet modifié dans lequel la DLL a été appelée ... l’application principale! Le fait de modifier la construction pour copier le DLL manquant dans le répertoire d’exécution du test a résolu le problème.
J'avais le même problème pour exécuter n'importe quel test en utilisant le framework NUnit. "Non concluant: le test ne s'exécute pas" Visual Studio 2017 15.5.6
ReSharper Ultimate 2017.3.3 Build 111.0.20180302.65130
RESOLU Ajout de la dépendance du projet à Microsoft.NET.Test.Sdk
J'utilise VS2013, ReSharper 9.1 avec l'extension MSpec de ReSharper et Moq. J'ai eu la même erreur "non concluante".
Il s'est avéré que celui de ma maquette de Moq n'était pas initialisé, mais seulement déclaré. Ceux initialisés tous les tests ont été exécutés à nouveau.
Dans mon cas, tous les tests de certains projets de test d'une solution ont commencé à ne pas s'exécuter après avoir ajouté de nouveaux projets. Utilisation de VS 2017 avec ReSharper 2017.1.2 ici.
Tout d’abord, assurez-vous de ne pas perdre de temps en supposant que votre problème est lié à ReSharper. Il est facile de supposer qu'il y a quelque chose qui ne va pas avec ReSharper si vous utilisez ses fonctionnalités de test unitaire, notamment Unit Test Explorer. Ouvrez Test Explorer de Visual Studio dans le menu Test et essayez Run All ". L’avantage supplémentaire de cette opération est que la fenêtre de sortie affiche un message d’erreur Si vous remarquez que les mêmes tests ne sont pas exécutés, il est prudent de supposer que le problème concerne Visual Studio et non ReSharper.
J'ai finalement supprimé et rajouté l'une des plates-formes solution active, Tout processeur, dans Configuration Manager. Ainsi, après avoir enregistré mes modifications et rouvert la solution, tous les tests ont recommencé.
Je pense qu'il y avait une entrée de configuration inattendue dans le fichier de solution lorsque j'ai ajouté de nouveaux projets et en recréant l'une des plates-formes, cela s'est corrigé. J'ai essayé de me différencier mais il était difficile de dire ce qui avait changé pour causer le problème.
Dans mon cas, ma méthode de test était privée, je l’ai changée en publique et cela a fonctionné.
Ma solution:
NUnit 3.2.0 a quelques problèmes avec Resharper - rétrograder à la version 2.6.4:
update-package nunit -version 2.6.4
J'ai fait face à ce problème dans vs 2017 update 3 avec Resharper Ultimate 2017.2
Redémarrer vs ou redémarrer la machine ne peut pas aider.
J'ai résolu le problème en effaçant le cache de la manière suivante:
Resharper ->options-> Environment ->click the button 'Clear caches'
Mettre à jour:
Il y a un bouton "erreur" (je trouve dans Resharper 2018) dans le coin supérieur droit de la fenêtre de test.
Si vous cliquez sur le bouton d'erreur, un message d'erreur peut vous aider à résoudre le problème.
Pour suivre la racine du problème, exécutez Visual Studio en mode journal. En vs 2017, exécutez la commande:
devenv /ReSharper.LogFile C:\temp\log\test_log.txt /ReSharper.LogLevel Verbose
Exécutez le test.
Consultez le fichier journal test_log.txt et recherchez "error" dans le fichier.
Le fichier journal est une aide précieuse pour trouver l'erreur que vous pouvez résoudre ou vous pouvez envoyer le problème avec le fichier journal à l'équipe de support technique de de Resharper .
J'ai eu le même problème. Le coupable était une référence externe non compatible avec les paramètres de construction de mon projet. Pour résoudre le problème, j'ai cliqué avec le bouton droit de la souris sur le projet-> Propriétés-> Construire-> Cible de la plate-forme-> Changer de Tout processeur en x86.
Le fichier * .dll avec lequel je travaillais était System.Data.SQLite. Ce fichier * .dll est codé en dur pour les opérations 32 bits. Le paramètre "Any CPU" a tenté de le charger en 64 bits.
J'utilise VS2010, NUnit 2.6.3 (bien que ReSharper indique en interne qu'il utilise 2.6.2?), ReSharper 7.7.1 et NCrunch 2.5.0.12 et que le même test "... n'est pas concluant ..." avec NUnit, mais NCrunch a dit que tout allait bien. Pendant la majeure partie de la journée, NUnit et NCrunch se sont accordés pour déterminer quels tests étaient satisfaisants et qui nécessitaient une refactorisation, puis il s'est passé quelque chose que je ne comprends toujours pas. Pendant un certain temps, NCrunch a déclaré que j'avais échoué aux tests passé), puis ont décidé qu’ils travaillaient tous, et NUnit a commencé à se plaindre de tous mes tests, sauf un avec le même message "Le test n’est pas concluant ...", ce que j’ai encore été en mesure d’aboutir, même si NUnit continue pour le montrer comme "non concluant").
J'ai essayé plusieurs des suggestions ci-dessus sans succès, et j'ai finalement fermé VS2010 et rouvert la solution. Voilà, tous mes tests sont à nouveau satisfaits, et NCrunch & NUnit signalent à nouveau les mêmes résultats. Malheureusement, je ne sais pas du tout ce qui a changé, ce qui a entraîné leur désynchronisation, mais la fermeture et la réouverture de VS2010 semble avoir résolu le problème.
Peut-être que quelqu'un d'autre rencontrera cela et sera capable d'utiliser cette solution simple (si finalement insatisfaisante puisque vous ne savez pas quelle est la véritable solution).
Si vous utilisez xUnit, j'ai résolu le problème de l'installation du package xunit.running.visualstudio . (Utilisant actuellement xUnit 2.3.1 et VS17 Enterprise 15.3.5).
Causé par le fichier App.Config manquant (non corrompu). L'ajout d'un nouveau (Ajouter -> Nouvel élément ... -> Fichier de configuration d'application) l'a corrigé.
Dans mon cas, ReSharper m'a donné cette exception supplémentaire dans la fenêtre de test:
2017.06.15 12:56:57.621 ERROR Exploration failed with the exception:
System.AggregateException: One or more errors occurred. ---> System.Threading.Tasks.TaskCanceledException: A task was canceled.
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at JetBrains.ReSharper.UnitTestFramework.Launch.Stages.DiscoveryStage.Run(CancellationToken token)
---> (Inner Exception #0) System.Threading.Tasks.TaskCanceledException: A task was canceled.<---
il s'est avéré que les projets de test générant cette erreur ne devaient pas être construits du tout dans Configuration Manager. Cochez la case pour construire les 2 projets de test et reconstruisez-les triés pour moi.
J'ai eu exactement le même problème et rien n'a aidé.
j'ai finalement constaté que mes espaces de noms du projet d'unité et du projet de test d'unité ne correspondaient pas.
L'espace de noms de mon projet d'unité est unit.project et le projet de test s'appelait unit.project.tests, mais l'espace de noms par défaut du test était identique à celui de l'unité. L'un et l'autre étaient unit.project.
Une fois que j'ai mis à jour les espaces de noms pour qu'ils soient différents (un espace de noms pour chaque projet), tout a fonctionné!
J'ai eu la même erreur dans VS2013 et Resharper9. Le problème était que j'ai oublié d'annoter la méthode de test avec [Test]:) J'espère que cela aidera tout le monde.
J'ai eu le même problème.Il était lié à la version de compatibilité entre NUnit 3.5 et Resharper 9.2, car elle a été résolue en rétrogradant de NUnit 3.5 à 2.6.4 . Cela a fonctionné pour moi . Bonne chance.
Dans mon cas, j'ai référencé 2 projets de mon projet unittest. Les deux projets référencés utilisaient une DLL avec le même nom, mais avec une version différente.
Je n'ai pas remarqué cela dans Visual Studio. J'ai remarqué l'erreur dans Eventviewer.
Pour résoudre ce problème, j'ai utilisé bindingRedirect dans le fichier app.config du projet unittest afin de corriger la version dll.
Tous les tests pour ma classe sont devenus peu concluants après quelques changements de code (ils passaient auparavant).
Il est apparu que j'avais ajouté un nouveau champ à mon cours de test:
private readonly Foo _foo = CreateFoo();
Le problème était qu'une exception avait été lancée à l'intérieur de 'CreateFoo ()', alors c'est arrivé pour tous les tests et au lieu d'échouer, ils sont tous devenus peu concluants.
J'ai eu exactement le même problème, aucun test n'a été exécuté dans mon projet-test. Comme cela est arrivé, la mauvaise configuration a été sélectionnée lors de l'exécution des tests. Revenir à Debug a corrigé les problèmes.
Comportement très étrange.
Je viens juste de déplacer une nouvelle entrée d'appsetting récemment ajoutée au bas de app.config qui a résolu mon problème.
<appSettings>
<add key="xxxxxx" value="xxxxx" />
</appSettings>
J'espère que cela aide quelqu'un
Pour moi, un test a créé cette erreur et il s’est avéré que j’avais involontairement ignoré le test. Sur la gauche de l'écran, lorsque vous cliquez pour définir un point d'arrêt, vous remarquerez peut-être que votre test est configuré pour être ignoré (une icône Microsoft l'indique). J'ai activé le test et l'erreur est partie.
Pour ceux qui sont pressés pour l'exécution des tests, j'ai dû utiliser VS 2017 test Explorer pour exécuter des tests.
Dans mon cas, nous avons constaté que le TestCaseSource a un nombre d'arguments différent du paramètre dans la méthode de test.
[Test, TestCaseSource("DivideCases")]
public void DivideTest(int n, int d, int q)
{
Assert.AreEqual( q, n / d );
}
static object[] DivideCases =
{
new object[] { 12, 3 },
new object[] { 12, 2 },
new object[] { 12, 4 }
};
Ici, chaque tableau d’objets dans DivideCases a deux éléments qui devraient être 3, la méthode DivideTest ayant 3 paramètres.
Si vous utilisez XUnit & Resharper, vous pouvez essayer de mettre à jour l'extension XUnit (pour moi).
Dans mon cas, c'est parce que les méthodes de test étaient "statiques"
Ce problème a commencé lorsque j'ai mis à niveau vers .NET Core 1.1.0
Résolu en ajoutant la dépendance suivante au fichier project.json du projet test:
"Microsoft.DotNet.InternalAbstractions": "1.0.500-preview2-1-003177"
Avait exactement la même chose qui m'arrive. Enfin, la mise à niveau de VS2010 à 2013 a été évitée et aucun des tests unitaires ne figurait dans la liste de VS et Resharper les a tous répertoriés comme ignorés. J'ai essayé à peu près tout ce qui est énuméré ici en vain. Nous avons fini par créer un tout nouveau projet de test unitaire et copié tous les fichiers .cs des anciens dans le nouveau, en reproduisant les références, etc., et tout fonctionnait correctement. Je suppose que quelque chose dans le projet de test a été cassé lors de la mise à niveau.
Cette erreur s'est produite avec Visual Studio 2017 et la version 2018.2.3 de resharper, mais le correctif s'applique aux versions de Visual Studio 2019.
Le correctif, pour que les tests fonctionnent dans Resharper, consistait simplement à mettre à jour la dernière version de Resharper (2019.2.1) au moment de la rédaction.
J'ai longtemps lutté contre ce problème et il semble qu'aucune des réponses ci-dessus ne résout mon problème.
J'ai finalement trouvé la raison dans mon cas:
J'ai spécifié un dossier pour l'option "Exécuter le test à partir de". Le dossier n'inclut pas la DLL à tester.
Resharper-> Options-> Outils-> Test unitaire, sélectionnez Dossier de sortie du projet sous Général.
J'utilisais VS2012 et ai fait la plupart de ceux-ci. Merci au meilleur développeur UV européen, qui a suggéré de désinstaller et de réinstaller specflow. Cela a résolu le problème!
J'espère que cela pourrait aider quelqu'un d'autre là-bas.
Si vous utilisez Nunit:
Pour moi, c’est que j’ai inclus les DLL suivantes:
nunit.core
nunit.framework
mais il devrait en fait être UNIQUEMENT: nunit.framework
J'ai donc retiré nunit.core et tout a bien fonctionné.
Parfois, il suffit d’essayer de supprimer le fichier d’en-tête (.h) et de le rajouter en tant que source (.cpp) PAS renommer. Test en resharp c ++ && vs2019, le code de test est ici
J'ai eu le même problème pour une raison qui ne figurait dans aucune des réponses disponibles: le code traité par l'un de mes tests (le premier exécuté) contenait un appel "Environment.Exit (-1)" .
Ce test a été signalé comme étant abandonné, tous les autres tests de la solution ont été signalés comme "non concluants: ne pas être exécutés" comme dans la question OP.
Dans mon cas, j'ai dû renommer une nouvelle référence que j'ai ajoutée, appelée Configuration.dll. Apparemment, Typemock a sa propre Configuration.dll (nom génial!) Et ma DLL l'a confondu.
J'ai utilisé la version ReSharper pour résoudre ce problème.
ReSharper => Options => Tools => Build => General => Use ReSharper Build
Après avoir effectué des séries de redémarrages, modifications et ajustements
la mise à niveau du package de nuget TestFramework pour utiliser le package suivant a fonctionné.
<package id="Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated" version="15.0.26228" targetFramework="net461" />
Dans mon cas, cela était dû à la transmission de\r\n caractères dans TestCase. Vous ne savez pas pourquoi cela cause des problèmes intermittents, car cela fonctionne la plupart du temps. Mais si je supprime\r\n le test n’est jamais concluant:
[TestCase("test\r\n1,2\r\n3,4", 1, 2)]
public void My_Test(string message, double latitude, double longitude)
Dans mon cas, je devais mettre à niveau ma ReSharper (vers la v. 10) pour qu'elle puisse utiliser la dernière version de NUnit (v. 3.0).
Depuis que ReSharper me donne du fil à retordre. J'ai décidé de le tester rapidement avec NUnit3 Test Adapter
https://visualstudiogallery.msdn.Microsoft.com/0da0f6bd-9bb6-4ae3-87a8-537788622f2d
J'avais un scénario similaire: tous mes tests fonctionnaient bien, j'en ai ajouté deux autres et soudain aucun de mes tests ne fonctionnait sous VS2015 avec R # 10.
J'ai essayé d'effacer le cache R #, de revenir sur les modifications apportées à app.config, de supprimer les 'assemblages de clichés instantanés en cours de test', de nettoyer/reconstruire, de redémarrer VS - tout cela en vain.
En fin de compte, un bon redémarrage à l'ancienne a résolu le problème pour moi.
Dans mon cas (Visual Studio Community 2017 version 15.2), la source du problème était la nouvelle méthode de chargement des projets introduite dans VS 2017, c’est-à-dire 'Lightweight Solution Load'.
Dans la fenêtre "Unités de tests unitaires", j'ai remarqué que la solution comportait beaucoup moins de tests qu'elle ne le devrait. Je devais ouvrir manuellement chaque projet de test unitaire dans "Solution Explorer", puis tous les tests étaient chargés et réussis.
Une solution consiste à désactiver "Lightweight Solution Load" en cliquant avec le bouton droit de la souris sur la solution dans "Solution Explorer" et en sélectionnant "Désactiver Lightweight Solution Load".
Je suis tombé sur le même problème aujourd'hui. Si aucune de ces réponses ne vous a aidé, essayez ceci:
Convertissez votre bibliothèque de classes en une application console. Puis essayez de trouver LoaderExceptions, expliqué ici: Comment diagnostiquer le testeur de l'unité Resharper Runner "Impossible de charger un ou plusieurs des types demandés" erreur
Si votre projet démarre sans aucune exception, essayez maintenant de le tester avec resharper. (sans reconvertir dans une bibliothèque de classe) Cela a fonctionné pour moi.
Ce qui a résolu le problème pour moi est l'exécution:
git clean -dfx
sur le repo, puis reconstruire.
J'utilise VS2013, Resharper 8.2 et NUnit (Runner) 2.6.3. Resharper configuré pour utiliser le coureur nunit installé via nuget.
J'ai la même erreur "Non concluante: le test n'a pas été exécuté" lors de la tentative d'exécution de tests unitaires avec resharper. Après avoir essayé différentes solutions, j'ai essayé de démarrer le fichier nunit.exe et le message d'erreur "Pour exécuter cette application, vous devez d'abord installer l'une des versions suivantes du fichier .NET.Framework: V4.0.30319"
Après avoir réparé mon installation .net framework 4.5, tout fonctionnait à nouveau correctement.
Dans mon cas, VS n'a pas été démarré avec Privilèges d'administrateur .
Quittez VS et choisissez "Exécuter en tant qu’administrateur". Ce problème sera résolu.
Juste pour ajouter une autre manière, cela peut arriver, à certains types d’erreurs d’exécution dans le test lui-même.
Je l'avais eu avec une exception de débordement de pile non interceptée se produisant dans une propriété dont je testais la valeur (avec VisualStudioTestingExtensions). J'avais une propriété (comme "IsFoo") qui avait elle-même un Select pour vérifier IsFoo sur les sous-objets. Mais, par erreur, avait foo.Select(x => IsFoo) au lieu de foo.Select(x => x.IsFoo).
Donc, si vous voyez que "La méthode de test n'est pas concluante ..." survient pour un seul test, assurez-vous également de procéder à un débogage. Cela révélera s'il s'agit de ce problème particulier (puisqu'il s'arrêtera au point d'exception).