NUnit 3 Erweiterung zu fehlgeschlagen Test auf einem fehlerhaften Debug.Assert

Question

Ich versuche, eine NUnit 3 (3.8.1) Erweiterung zu schreiben, die einen Test fehlschlägt, wenn es einen Fehler Debug.Assert(...) hat (anstatt still durchzulaufen oder sogar hängen weil es den fehlgeschlagenen Assertion-Dialog anzeigt).

In einem NUnit 2 Addin, konnte ich so durch die Registrierung alle Debug-Trace-Listener und das Hinzufügen meiner eigenen, die nur eine Ausnahme löst (wie zum Beispiel erklärt here). Dies scheint jedoch auf NUnit 3 nicht mehr zu funktionieren.

Ich bin in der Lage, die Erweiterung erfolgreich bereitzustellen, und der Code wird ausgeführt.

[Extension(Description = "Failed Assertions Tracker", EngineVersion = "3.4")] 
public class TrackerEventListener : ITestEventListener 
{ 
    public void OnTestEvent(string report) 
    { 
     Console.WriteLine(report); // prints -> so I know this method is being called 
     Debug.Listeners.Clear(); 
     Debug.Listeners.Add(new UnitTestTraceListener()); 
    } 
} 

jedoch mein Unit-Test mir leider zeigt, dass nach wie vor die DefaultTraceListener installiert ist.

[Test] 
public void FailingAssertionShouldNotHang() 
{ 
    foreach (object listener in Debug.Listeners) 
    { 
     Console.WriteLine(listener.GetType().FullName); 
    } 
    Debug.Fail("I'm sorry. I've failed."); 
} 

Und so zeigt der Test den Dialog statt einfach zu scheitern.

Was mache ich falsch? Ich vermute, dass der Aufruf an die statische Listeners Sammlung ineffektiv ist, weil der eigentliche Test in einem anderen Kontext ausgeführt wird (andere AppDomain, Prozess,?). Aber wenn das der Fall ist, wie kann ich mein Problem lösen?

Answer 1

Es ist wichtig, daran zu denken, dass NUnit 3 Extensions, obwohl sie NUnit 2 Addins in einigen Fällen ersetzen können, eigentlich völlig unterschiedliche Technologien sind. NUnit 3 Extensions erweitern die Engine, die vom Framework getrennt ist.

In diesem Fall richtet Ihre Erweiterung einen Trace Listener ein, der alle Debug-Trace- oder Assert-Ausgaben erfasst, die von der Engine erzeugt werden. Wenn die Engine Trace-Anweisungen enthält (nicht), erhalten Sie die Ausgabe. Inzwischen führt das Framework erfreulicherweise weiterhin Tests selbst durch.

Jeder Code, der Trace erfolgreich erfassen kann, muss Teil der eigentlichen Framework-Ausführung der Tests sein. Dies gibt Ihnen zwei Möglichkeiten.

1. Erstellen Sie ein benutzerdefiniertes Attribut, das die Ablaufverfolgung erfasst. Mit benutzerdefinierten Attributen können Sie Aktionen ausführen, wenn ein Test erstellt oder ausgeführt wird. Sie werden durch die Implementierung verschiedener Schnittstellen erstellt, die vom Framework unterstützt werden. In Ihrem Fall möchten Sie das Attribut auf Assembly-Ebene bereitstellen, um die von der Baugruppe ausgegebene -Ausgabe zu erfassen.

2. Erstellen Sie den Code als Teil Ihrer Tests selbst, ohne das Framework überhaupt zu erweitern. Sie möchten die Trace-Ausgabe in einer Assembly-Ebene SetUpFixture mit dem Attribut OneTimeSetUp erfassen und unter dem Attribut OneTimeTearDown freigeben. Da dieser Ansatz einfacher ist als das Erstellen eines benutzerdefinierten Attributs, würde ich es verwenden.