2017-08-31 1 views
0

Dies ist keine Frage zu Setup und Teardown. Dies ist keine Frage zu Bestellattributen.Holen Sie sich Nunit-Testauftrag nach der Ausführung, um spröde Tests zu analysieren

Wenn ich meine Nunit Tests starte, tötet einer von ihnen eine Abhängigkeit, auf die andere Tests angewiesen sind. Meine Zusammenfassung zeigt viele fehlgeschlagene Tests.

Ein guter Startpunkt wäre der letzte Test, der durch nachfolgende Fehler nach unten arbeitet. Ich muss mir die Protokolldateien der Tests ansehen oder etwas Besseres.

Ich verwende die Tests mit dem Testadapter im Visual Studio.

Hier sind meine Pakete:

<?xml version="1.0" encoding="utf-8"?> 
<packages> 
    <package id="Castle.Core" version="3.3.3" targetFramework="net452" /> 
    <package id="NUnit" version="3.5.0" targetFramework="net452" /> 
    <package id="NUnit3TestAdapter" version="3.6.0" targetFramework="net452" /> 
    <package id="RhinoMocks" version="3.6.1" targetFramework="net452" /> 
    <package id="TestStack.White" version="0.13.3" targetFramework="net452" /> 
</packages> 

ich kann nicht herausfinden, wo die Log-Dateien des letzten Testlauf sind. Das Durchsuchen des Web- oder Stack-Overflows hat mir nicht geholfen. Ich habe möglicherweise falsche Suchbegriffe verwendet.

Mein Problem ist, dass ich den einen Test finden muss, der brüchig ist und nachfolgende Tests nicht besteht, damit ich herausfinden kann, wie man das repariert.

EDIT: Ich fand etwas über einen Tracelogger. Ich kann es aktivieren, indem ich die OneTimeSetUp meiner Basis SetUpFixture verwende. InternalTrace.Initialize(TestContext.CurrentContext.WorkDirectory + "nunittrace.log", InternalTraceLevel.Debug); Leider hatte dies keine wirkliche Wirkung, die Datei enthält nur eine Zeile, die die Initialisierung bestätigt.

EDIT: Ich möchte nicht auf die Reihenfolge der Tests verlassen oder die Reihenfolge der Tests zu kontrollieren. Das Markieren von Tests mit einem Order-Attribut kommt nicht in Frage. Was ich will, ist die Testbestellung nach der Ausführung zu betrachten, damit ich herausfinden kann, was genau diese Tests brüchig macht, um sie zu reparieren, indem ich diese Sprödigkeit kontrolliere. Setup/Teardown, ein anderes Interface? alle Optionen, die ich habe, sobald ich das Problem finde.

+0

Wenn Sie Tests erstellen, die von der Reihenfolge abhängen, in der Sie brüchige Tests durchführen, ** tun Sie das nicht! **. –

+0

@ LasseV.Karlsen Ich stimme völlig zu, deshalb möchte ich den Sprödtest finden, damit ich es beheben kann. Ich schaue nicht, wie ich die Reihenfolge kontrollieren kann, ich bin auf der Suche nach einer Log-Datei, die mir die Reihenfolge nach der Tat sagt, damit ich die spröde identifizieren kann. Im Moment kann ich dir sagen, dass ich x rot und y grün habe. wenn ich alle starte und x + y grün, wenn ich die roten wiederhole. Ich glaube, Gruppe y beeinflusst etwas, das x rot macht. Ich kann nicht finden, was das ist. Ich brauche ein Logfile, damit ich herausfinden kann, wo ich suchen muss. – Johannes

Antwort

1

Mit einem Problem dieser Art würde ich den Konsolen-Runner anstelle des VS-Adapters verwenden. Die Option --labels:Before gibt Ihnen eine Liste aller Tests in der Reihenfolge, in der sie ausgeführt werden.

Wenn Sie eine parallele Ausführung verwenden, sollten Sie diese für diese Testläufe deaktivieren. Sie können dies in der Konsole tun, ohne Ihren Testcode zu bearbeiten, indem Sie --workers=0 in der Befehlszeile verwenden.

Verwandte Themen