Comment diagnostiquer «TestFixtureSetUp Failed»

Question

Nous utilisons TeamCity comme serveur CI, et je viens de commencer à voir "TestFixtureSetUp Failed" dans la fenêtre "Echec du test".

Avez-vous une idée de la façon dont je vais résoudre ce problème? Les tests fonctionnent correctement sur mon poste de travail (testeur R # dans VS2008).

Answer 1

La mise en œuvre de TestFixtureSetUp (et de TestFixtureTearDown) est un peu faussée par le fait que toutes les exceptions ne sont pas bien signalées. J'ai écrit leur première implémentation et je n'ai jamais réussi à la faire fonctionner comme prévu. À l'époque, les concepts du code NUnit étaient étroitement associés à l'idée que les actions étaient directement liées à un seul test. Donc, le compte rendu de tout était lié à un résultat de test. Il n'y avait pas vraiment d'espace pour signaler quelque chose qui se produisait au niveau de la suite sans une réécriture énorme (ce n'est pas un refactoring lorsque vous changez un mouton en escalator).

À cause de ce peu d'histoire, il est difficile de savoir ce qui s'est réellement passé dans TestFixtureSetUp. Il n'y a pas de bon endroit pour attacher l'erreur. L'appel TestFixtureSetUp est un effet secondaire de l'exécution d'un test au lieu d'être directement lié à celui-ci.

@TrueWill a la bonne idée. Vérifiez les journaux, puis modifiez le test pour ajouter davantage de journalisation si nécessaire. Vous voudrez peut-être mettre try / catch à l'intérieur de TestFixtureSetup et vous connecter beaucoup dans le bloc catch. Je pensais juste pouvoir ajouter un peu d’arrière-plan (c’est un peu de ma faute).

Answer 2

Je vérifierais d'abord le journal de construction.

Si cela ne vous semble pas évident, vous pouvez essayer d’inclure Console.WriteLines dans les tests - je ne suis pas positif, mais je pense que ceux-ci sont écrits dans le journal de construction. Sinon, vous pouvez vous connecter à un fichier (même en utilisant log4net si vous voulez avoir envie de jouer).

Si Visual Studio est installé sur le serveur CI, vous pouvez essayer d’exécuter la compilation / tests à partir de cet emplacement. S'il s'agit d'un problème de connectivité, cela pourrait le résoudre.

J'ai toutefois rencontré des problèmes de chemin d'accès, où les chemins d'accès relatifs aux fichiers n'étaient plus corrects ou des chemins d'accès absolus utilisés. Celles-ci sont plus difficiles à déboguer et peuvent nécessiter la journalisation des chemins, puis la vérification de leur existence sur le serveur de compilation.

Answer 3

Je me suis heurté à cela aujourd'hui en créant des tests d'intégration dont la configuration est longue et que je ne veux pas dupliquer. J'ai fini par envelopper toute la logique d'installation de test dans un try / catch. J'ajoute ensuite une méthode SetUp dont le seul but est de voir si une défaillance s'est produite lors de la configuration de la fixture et de fournir une meilleure journalisation.

Exception testFixtureSetupException = null;

[TestFixtureSetUp]
public void FixtureSetup()
{
    try
    {
        // DoTestFixtureSetup
    }
    catch (Exception ex)
    {
        testFixtureSetupException = ex;
    }
}

[SetUp]
// NUnit doesn't support very useful logging of failures from a TestFixtureSetUp method. We'll do the logging here.
public void CheckForTestFixturefailure()
{         
    if (testFixtureSetupException != null)
    {
        string msg = string.Format("There was a failure during test fixture setup, resulting in a {1} exception. You should check the state of the storage accounts in Azure before re-running the RenewStorageAccountE2ETests. {0}Exception Message: {3}{0}Stack Trace:{4}",
            Environment.NewLine, testFixtureSetupException.GetType(), accountNamePrefix, testFixtureSetupException.Message, testFixtureSetupException.StackTrace);
        Assert.Fail(msg);
    }
 }

Answer 4

La même erreur s'est produite lors de l'exécution de tout test avec SpecFlow à l'aide de Visual NUnit. Lorsque j'ai essayé de procéder de la même manière à partir de Unit Test Explorer (fourni par Resharper), un message un peu plus utile s’est affiché: Les méthodes de liaison avec plus de 10 paramètres ne sont pas prises en charge. J'ai réalisé que je ne pouvais pas utiliser une méthode SpecFlow avec plus de 10 paramètres, je devais supprimer le test.

Answer 5

J'ai pu constater que je ne créais pas correctement ma base de données de tests en passant rapidement à VS Unit Testing. Dans mon cas, il a été en mesure de donner une meilleure réponse à la raison de son échec. J'utilise habituellement NUnit. " Impossible de créer une instance de classe X. Erreur: System.Data.SqlClient.SqlException: une erreur d'activation de fichier s'est produite. Le nom de fichier physique '\ DbTest.mdf' est peut-être incorrect. Diagnostiquez et corrigez les erreurs supplémentaires, puis renouvelez l'opération. CREATE DATABASE a échoué. Certains noms de fichiers répertoriés n'ont pas pu être créés. Vérifier les erreurs liées .. "

Answer 6

Exécutez le test unitaire en mode débogage . Vous pouvez trouver une erreur d’exécution lors de la configuration.

Answer 7

Si vous utilisez SpecFlow et C # dans Visual Studio, examinez le fichier généré automatiquement, quel que soit le fichier > .feature.cs après l'échec du test. Sur la ligne classe partielle publique < quelle que soit la fonction > Feature , vous devriez voir un symbole qui, une fois survolé, indiquera la raison de l'échec de la configuration du projecteur NUnit. Dans mon cas, certaines de mes méthodes BeforeFeature de ma classe TestHooks n'étaient pas statiques. Toutes les méthodes BeforeTestRun , AfterTestRun , BeforeFeature et AfterFeature doivent être statiques.

Answer 8

J'ai eu ce problème et il a été provoqué par l'ajout d'un Dictionnaire privé en lecture seule dans la classe, de la même manière que vous ajoutez une chaîne private const .

J'ai essayé de faire du Dictionary une constante, mais vous ne pouvez pas le faire au moment de la compilation. J'ai résolu ce problème en plaçant mon dictionnaire dans une méthode qui le renvoie.

Answer 9

J'ai eu ce symptôme causé par une erreur lors de l'initialisation du champ. Si vous initialisez vos champs dans la méthode [SetUp] , vous devriez voir un meilleur message d'erreur.

[TestFixture]
internal class CommandParserTest
{
    // obscure error message
    private CommandParser parser = new CommandParser(...);
    ...
}

[TestFixture]
internal class CommandParserTest
{
    private CommandParser parser;

    [SetUp]
    public void BeforeTest()
    {
        // better error message
        parser = new CommandParser(...);
    }
    ...
}

Answer 10

Cela me trouble aujourd'hui. J'ai fait ce qui suit pour obtenir l'erreur réelle.

(1) Ecrivez un autre test dans un appareil séparé qui initialise une instance du dispositif de test qui pose problème, appelle explicitement les méthodes d'installation telles que TestFixtureSetUp et SetUp, le cas échéant, puis exécute la méthode d'essai cible.

(2) Ajoutez le code de gestion des exceptions pour le nouveau code ci-dessus et enregistrez / exportez l'exception réelle vers quelque part.

Answer 11

Si cela peut aider quelqu'un: Vous pouvez intercepter l’exception et l’écrire dans la console sous TearDown

Quelque chose comme:

[SetUpFixture]
public class BaseTest
{
    private Exception caughtException = null;

    [SetUp]
    public void RunBeforeAnyTests()
    {
        try
        {
            throw new Exception("On purpose");
        }
        catch (Exception ex)
        {
            caughtException = ex;               
        }
    }

    [TearDown]
    public void RunAfterAnyTests()
    {
        if (caughtException != null)
        {
            Console.WriteLine(string.Format("TestFixtureSetUp failed in {0} - {1}", this.GetType(), caughtException.Message));
        }           
    }

}

Et le résultat sera:

TestFixtureSetUp a échoué dans IntegratedTests.Services.BaseTest - Exact