Wie zu diagnostizieren „TestFixtureSetUp Failed“

Question

Wir verwenden Teamcity als unseren CI-Server, und ich habe gerade erst begonnen "TestFixtureSetUp Failed" im Testfehler Fenster zu sehen.

Jede Idee, wie ich über das Debuggen dieses Problems zu gehen? Die Tests laufen auf meinem Arbeitsplatz (R # Test-Runner in VS2008).

Answer 1

Es ist ein bisschen ein Fehler bei der Umsetzung von TestFixtureSetUp (und TestFixtureTearDown), dass alle Ausnahmen sind nicht gut berichtet. Ich schrieb die erste Implementierung von ihnen, und ich habe es nie den Weg zur Arbeit sollte zu. Zu der Zeit wurden die Konzepte in dem NUnit Code gekoppelt fest an die Idee, dass die Maßnahmen auf einen einzigen Test direkt verbunden waren. So ist die Berichterstattung über alles wurde zu einem Testergebnis zusammen. Es war etwas, das nicht wirklich ein Raum für die Berichterstattung, die ohne großes Umschreiben auf der Suite Ebene passiert ist (es ist kein Refactoring ist, wenn Sie ein Schaf verwandeln sich in eine Rolltreppe).

Aufgrund dieses Stück Geschichte, es ist schwer, herauszufinden, was wirklich in einem TestFixtureSetUp passiert ist. Es ist kein guter Ort, um den Fehler zu befestigen. Der TestFixtureSetUp Anruf ist ein Nebeneffekt der einen Test statt laufen direkt mit ihm in Beziehung steht.

@TrueWill hat die richtige Idee. Überprüfen Sie die Protokolle und dann den Test ändern, um mehr Protokollierung bei Bedarf hinzufügen. Vielleicht möchten Sie bei Versuch setzen / innen der TestFixtureSetup fangen und eine Menge im catch-Block einloggen. Ich dachte nur, ich könnte einige Hintergrundinformationen, um es hinzuzufügen (in anderen Worten: es ist eine Art meiner Schuld).

Answer 2

Ich würde die Build Log überprüfen Sie zuerst.

Wenn es aus, dass nicht klar ist, könnten Sie mit Console.WriteLines in den Tests versuchen - ich bin nicht positiv, aber ich denke, diejenigen, die Build Log geschrieben werden. Alternativ könnten Sie in einer Datei protokolliert (auch mit log4net, wenn Sie Lust bekommen wollte).

Wenn Sie Visual Studio auf dem CI-Server installiert haben, versuchen Sie könnten die build / Tests von dort ausgeführt werden. Wenn es ein Verbindungsproblem ist, das könnte es lösen.

Ich habe Probleme gesehen Weg, obwohl, wo relative Pfade zu Dateien nicht mehr korrekt oder absolute Pfade verwendet. Diese sind schwerer zu debuggen und erfordern möglicherweise die Pfade anmelden und dann überprüft, ob sie auf dem Build-Server vorhanden sein.

Answer 3

ich in diese heute lief, als einige Integrationstests zu schaffen, die lange Setup ausgeführt haben, die ich will nicht duplizieren. Ich beenden alle Prüfadapter Setup-Logik in einem try / catch Einwickeln. Ich füge dann eine SetUp-Methode, deren einziger Zweck es ist, zu sehen, ob ein Fehler während der Befestigung Einrichtung aufgetreten und eine bessere Protokollierung liefern.

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

Ich war immer die gleichen Fehler während jeder Test läuft mit SpecFlow von Visual NUnit verwenden. Als ich versuchte, das auch von der Einheit Test Explorer (von ReSharper zur Verfügung gestellt) zu tun, gab es eine wenig hilfreiche Nachricht: Bindungsmethoden mit mehr als 10 Parametern werden nicht unterstützt. Ich erkannte ich kein SpecFlow Verfahren mit mehr als 10 params haben kann, hatte den Test zu entfernen.

Answer 5

Ich konnte sehen, dass ich nicht meine Testdatenbank wurde die Erstellung richtig durch eine schnelle Umstellung auf VS Unit Testing zu tun. In meinem Fall war es in der Lage eine bessere Antwort auf den Grund, zurückzukehren, warum es fehlgeschlagen. Normalerweise verwende ich NUnit. „Kann nicht Instanz der Klasse X. Fehler erstellen: System.Data.SqlClient.SqlException: Eine Datei Aktivierungsfehler aufgetreten Der physische Dateiname‚\ DbTest.mdf‘ist möglicherweise falsch machen und beheben zusätzliche Fehler, und wiederholen Sie den Vorgang... CREATE DATABASE schlug fehl. Einige Dateinamen aufgelistet konnte nicht erstellt werden. Überprüfen Fehler .. „

Answer 6

Führen Sie das Gerät zu testen in Debug-Modus . Sie können einen Laufzeitfehler in dem Setup finden.

Answer 7

Wenn Sie SpecFlow und C # in Visual Studio verwenden, sehen Sie die automatisch generierte <whatever>.feature.cs Datei nach dem Test fehlschlägt. Auf der public partial class <whatever>Feature Linie, sollten Sie ein Symbol sehen, die, wenn sie schwebt über den Grund zeigen, dass der NUnit Befestigungsaufbau fehlgeschlagen. In meinem Fall war es, dass einige meiner BeforeFeature Methoden in meiner TestHooks Klasse nicht statisch waren. Alle BeforeTestRun, AfterTestRun, BeforeFeature und AfterFeature Methoden müssen statisch sein.

Answer 8

hatte ich dieses Problem und es wurde durch Zugabe einen privaten Nur-Lese-Dictionary in der Klasse verursacht, viel die gleiche Weise, dass Sie ein private const string hinzufügen.

Ich habe versucht, die Dictionary eine Konstante zu machen, aber Sie können bei der Kompilierung nicht tun. Ich löste dies durch meinen Dictionary in einem Verfahren setzen, die es gibt.

Answer 9

hatte ich dieses Symptom durch einen Fehler bei der Feld Initialisierung verursacht. Wenn Ihr Ihre Felder in der [SetUp] Methode initialisieren, sollten Sie eine bessere Fehlermeldung angezeigt.

[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

Ich war von dieser heute beunruhigt. Ich habe die folgenden, die tatsächlichen Fehler zu erhalten.

(1) ein weiteren Test in einer separaten Halterung, die eine Instanz des beunruhigenden Prüfadapter initialisiert, explizit Setup-Verfahren wie TestFixtureSetUp und Einrichtung, wenn keine Anrufe, und führt dann die Zieltestmethode.

(2) In Ausnahmebehandlung Code für den neuen Code oben, und log / Ausgabe die tatsächliche Ausnahme irgendwo.

Answer 11

Falls es jemand helfen kann: Sie können die Ausnahme abfangen und in der Konsole auf dem TearDown schreiben

So etwas wie:

[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));
        }           
    }

}

Und das Ergebnis wird sein:

TestFixtureSetUp scheiterte in IntegratedTests.Services.BaseTest - Absichtlich