c# - visual - xunit vs nunit




La méthode de test n'est pas concluante: le test n'a pas été exécuté. Erreur? (20)

J'ai une classe de test et ci-dessous j'ai posté un test d'échantillon 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());
        }
    }
}

Quand je lance le projet, j'obtiens l'écran suivant

J'ai vérifié les références et le projet de test a la référence au projet principal. Une idée de pourquoi les tests ne sont pas en cours d'exécution ou de dire qu'ils n'étaient pas concluants?

Modifier 1:

J'ai vu un post here et j'ai changé l'architecture de processeur par défaut de mon test en X64 mais ça ne marche toujours pas.


Avez-vous ajouté une dépendance DLL récemment? ... comme moi

J'ai juste couru dans le même problème et il était très exaspérant de ne pas avoir la moindre idée dans la fenêtre de sortie de test ou ailleurs pratique.

La cause était extrêmement stupide: j'ai juste ajouté la veille de la dépendance à une DLL externe supplémentaire dans un sous-projet, et l'application principale du projet a bien été construite et exécutée correctement après le changement. Mais mes tests unitaires sont dans un projet frère de l'application principale, et ont donc aussi la dépendance de ce sous-projet modifié où la DLL a été invoquée ... encore, l'emplacement d'exécution du projet de test n'est pas celui de l'application principale! Donc, changer la compilation pour copier la DLL manquante dans le répertoire d'exécution du test a résolu le problème.


C'était un problème de Resharper. Dans les options Resharper-> Outils-> MSTEST, j'ai décoché l'utilisation de Legacy Runner et maintenant cela fonctionne.


Dans mon cas j'ai eu cette erreur à cause du mode 'Release' où la construction du projet UnitTests était simplement désactivée. Le retour au mode 'Debug' l'a corrigé.

Il est vraiment surprenant que ReSharper ne puisse rien dire au cas où il ne trouverait pas du tout la bibliothèque UnitTests. Sérieusement, c'est une honte;)

J'espère que ça va aider quelqu'un


Dans mon cas trouvé que le TestCaseSource a un nombre différent d'arguments que le 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 car la méthode DivideTest a 3 paramètres.


Dans mon cas, c'était une erreur que j'ai faite en copiant la chaîne de connexion dans le fichier app.config. Je l'avais placé dans la balise configSections!

Cela m'a pris un moment pour me rendre compte que ... merci VS IntelliSense si ... ou était-ce resharper?


Dans mon cas, j'ai créé une méthode de test asynchrone qui renvoyait void . Returning of Task au lieu de void résolu le problème.


Dans mon cas, ma méthode de test était privée, je l'ai changé en public et cela a fonctionné.


J'ai eu exactement le même problème et rien n'a aidé.

Finalement, j'ai vu que j'avais un décalage dans mes espaces de noms du projet d'unité et du projet de test unitaire.

L'espace de nom de mon projet d'unité est unit.project et le projet de test s'appelait unit.project.tests mais l'espace de nom par défaut du test était le même que l'unité, les deux étant unit.project.

Une fois que j'ai mis à jour les espaces de noms pour être différent (un espace de nom pour chaque projet) tout a fonctionné!


J'ai eu la même erreur dans VS2013 et Resharper9. Le problème était parce que j'ai oublié d'annoter la méthode de test avec [Test] :) J'espère que cela 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

Je devais simplement décocher l'option "Assemblages de copies fantômes en cours de test"


J'ai eu le même problème.Il était lié à la version de compatibilité entre NUnit 3.5 et Resharper 9.2, car il a été résolu en rétrogradant de NUnit 3.5 à 2.6.4. Cela a fonctionné pour moi. bonne chance.


J'ai eu problème similaire. VS 2010, c # CLR 2 Nunit 2.5.7, juste construire> solution propre de VS a aidé à résoudre ce problème


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 .

  1. Décochez "Créer uniquement des projets de démarrage et des dépendances sur Exécuter" (Options -> Projets et solutions -> Construire et exécuter)
  2. Dans Configuration Manager, assurez-vous que le projet de démarrage et le projet de test ont coché "Build".

La deuxième fois que j'ai rencontré ce problème, c'était dû à une esperluette dans le chemin du fichier vers le projet où les tests résidaient. Cela fonctionne bien avec le lanceur de test de ReSharper, mais pas avec dotCover. Supprimez l'esperluette du chemin de fichier.

Ceci est un bug confirmé avec dotCover.


J'utilise VS2010, NUnit 2.6.3 (bien que ReSharper indique en interne qu'il utilise 2.6.2?), ReSharper 7.7.1 & NCrunch 2.5.0.12 et fonctionnait dans la même chose "... test n'est pas concluant ..." avec NUnit, mais NCrunch a dit que tout allait bien. Pendant la majeure partie de la journée, NUnit & NCrunch se sont mis d'accord sur les tests qui étaient satisfaisants et qui nécessitaient un refactoring, puis quelque chose est arrivé que je ne comprends toujours pas et pendant un moment NCrunch a dit que j'avais échoué aux tests. pass), puis a décidé qu'ils travaillaient tous, et NUnit a commencé à se plaindre de tous mes tests sauf un avec le même message "..test n'est pas concluant ..." que j'ai encore pu passer à un passage même si NUnit a continué pour le montrer comme "non concluant").

J'ai essayé plusieurs des suggestions ci-dessus en vain, et finalement fermé juste VS2010 et rouvert la solution. Voila, maintenant tous mes tests sont de nouveau heureux, et NCrunch & NUnit rapportent encore les mêmes résultats. Malheureusement, je n'ai aucune idée de ce qui a changé pour les amener à se désynchroniser, mais la fermeture et la réouverture du VS2010 semblent l'avoir corrigé.

Peut-être que quelqu'un d'autre se heurtera à cela et sera capable d'utiliser cette solution simple (si finalement insatisfaisante puisque vous ne savez pas quelle est la vraie solution).


Juste au cas où aucune des options ci-dessus a travaillé pour quelqu'un, j'ai corrigé mon instance de cette erreur en notant une entrée corrompue dans mon App.Config en raison d'un paquet de nuget manquant dans le projet de test.


Ma solution:

NUnit 3.2.0 a quelques problèmes avec Resharper - downgrade à 2.6.4:

update-package nunit -version 2.6.4

Pour moi, c'était plutôt frustrant, mais j'ai trouvé une solution pour mon cas au moins:

Si votre méthode de test est asynchrone, elle ne peut pas être annulée. Il DOIT retourner la tâche.

J'espère que ça aide quelqu'un :)


Pour moi, le problème était un fichier XML de paramètres NUnit / ReSharper corrompu (en raison d'une panne de courant inattendue).

Pour identifier l'erreur, j'ai démarré Visual Studio avec cette commande :

devenv.exe /ReSharper.LogFile C:\temp\resharper.log /ReSharper.LogLevel Verbose

L'examen du fichier 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 ce n'est pas le fichier app.config du projet de test!

Un rapide googling autour identifié le fichier suivant comme le coupable:

%LOCALAPPDATA%\NUnit\Nunit30Settings.xml

Il existait, mais était vide. La suppression et le redémarrage de Visual Studio ont résolu le problème.

(À l'aide de Visual Studio Professional 2017 v15.3.5 et ReSharper 2017.2.1).


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, où vous cliquez pour mettre un point d'arrêt, vous pouvez remarquer que votre test est configuré pour être ignoré (il y a une icône Microsoft pour l'indiquer). J'ai activé le test et l'erreur est partie.


Provoqué par le fichier App.Config manquant (non corrompu). L'ajout de nouveau (Ajouter -> Nouvel élément ... -> Fichier de configuration de l'application) l'a corrigé.







resharper