2010-04-18 7 views
8

mam tę właściwość:Czy mogę skonfigurować NUnit, aby Debug.Fail nie wyświetlał okna komunikatu po uruchomieniu testów?

public SubjectStatus Status 
    { 
     get { return status; } 
     set 
     { 
      if (Enum.IsDefined(typeof(SubjectStatus), value)) 
      { 
       status = value; 
      } 
      else 
      { 
       Debug.Fail("Error setting Subject.Status", "There is no SubjectStatus enum constant defined for that value."); 
       return; 
      } 
     } 
    } 

i ten test jednostki

[Test] 
    public void StatusProperty_StatusAssignedValueWithoutEnumDefinition_StatusUnchanged() 
    { 
     Subject subject = new TestSubjectImp("1"); 

     // assigned by casting from an int to a defined value 
     subject.Status = (SubjectStatus)2; 
     Assert.AreEqual(SubjectStatus.Completed, subject.Status);    

     // assigned by casting from an int to an undefined value 
     subject.Status = (SubjectStatus)100; 
     // no change to previous value 
     Assert.AreEqual(SubjectStatus.Completed, subject.Status);    
    } 

Czy istnieje sposób mogę zapobiec Debug.Fail wyświetlając okno komunikatu, gdy uruchomię moich testów, ale pozwolić mu pokazać mnie, kiedy debuguję aplikację?

+0

Zaktualizowałem swoją odpowiedź, aby zawierała implementację wtyczki śledzenia śledzenia dla NUnit, jeśli jesteś zainteresowany. –

+0

Świetne, właśnie takie informacje, których szukałem! – Grokodile

Odpowiedz

2

standardowy sposób zawsze zrobić to stworzyć plugin NUnit. Wtyczka po prostu wyrejestruje domyślny detektor śledzenia i zarejestruje zamiennik, który zgłasza wyjątek po uruchomieniu Assert/Trace.Fail. Podoba mi się to podejście, ponieważ testy nadal będą nieskuteczne, jeśli wystąpią awarie, nie pojawi się żaden komunikat i nie trzeba modyfikować kodu produkcyjnego.

Edytuj - oto kod wtyczki w całości. Jesteś na własną rękę do budowania rzeczywistego wtyczki chociaż - sprawdź witrynę NUnit :)

[NUnitAddin] 
public class NUnitAssertionHandler : IAddin 
{ 
    public bool Install(IExtensionHost host) 
    { 
     Debug.Listeners.Clear(); 
     Debug.Listeners.Add(new AssertFailTraceListener()); 
     return true; 
    } 

    private class AssertFailTraceListener : DefaultTraceListener 
    { 
     public override void Fail(string message, string detailMessage) 
     { 
      Assert.Fail("Assertion failure: " + message); 
     } 

     public override void Fail(string message) 
     { 
      Assert.Fail("Assertion failure: " + message); 
     } 
    } 
} 
+0

Brzmi nieźle, czy łatwo jest napisać wtyczkę NUnit? – Grokodile

+0

To nie jest tak źle, jest kilka rzeczy związanych z ustawianiem plików do kopiowania local = false i innych dziwactw, ale nie mam tutaj tego projektu w tej chwili, więc nie mogę opublikować dokładnego kroki. Jest to dosłownie plugin .dll z jedną klasą, ale :) –

0

Zamiast wywoływać Debug.Assert bezpośrednio, można wywołać metodę wrapper, która sprawdza, czy debugger jest dołączony przed wywołaniem Debug.Assert. (Można przypuszczać, że powinna ona wyjątek, jeśli nie ma debugger przymocowany tak, że testy nie powiedzie się.) Np .:

[Conditional("DEBUG")] 
public static void Assert(bool condition) 
{ 
    if (Debugger.IsAttached) 
    { 
     Debug.Assert(condition); 
    } 
    else 
    { 
     throw new SomeException(); 
    } 
} 
+0

Dzięki, napiszę sobie klasę opakowania, którą mogę zmienić, dobry pomysł. – Grokodile

8

Alternatywny sposób, który nie wymaga wymiany kod produkcyjny lub pisząc zwyczaj NUnit dodatek byłby aby zastąpić detektory śledzenia w urządzeniu konfiguracyjnym.

E.g. Dodaj następującą klasę w przestrzeni nazw, w której znajdują się twoje testy:

using System; 
using System.Diagnostics; 
using NUnit.Framework; 

[SetUpFixture] 
public class NUnitSetup 
{ 
    // Field to hold exisitng trace listeners so they can be restored after test are run. 
    private TraceListener[] originalListeners = null; 

    // A trace listener to use during testing. 
    private TraceListener nunitListener = new NUnitListener(); 

    [SetUp] 
    public void SetUp() 
    { 
     // Replace existing listeners with listener for testing. 
     this.originalListeners = new TraceListener[Trace.Listeners.Count]; 
     Trace.Listeners.CopyTo(this.originalListeners, 0); 
     Trace.Listeners.Clear(); 
     Trace.Listeners.Add(this.nunitListener); 
    } 

    [TearDown] 
    public void TearDown() 
    { 
     // Restore original trace listeners. 
     Trace.Listeners.Remove(this.nunitListener); 
     Trace.Listeners.AddRange(this.originalListeners); 
    } 

    public class NUnitListener : DefaultTraceListener 
    { 
     public override void Fail(string message) 
     { 
      Console.WriteLine("Ignoring Debug.Fail(\"{0}\")", message); 
     } 

     public override void Fail(string message, string detailMessage) 
     { 
      Console.WriteLine("Ignoring Debug.Fail(\"{0},{1}\")", message, detailMessage); 
     } 
    } 
} 
+1

Nie potrzebujesz nawet niestandardowego detektora śledzenia, wystarczy zainstalować ConsoleTraceListener. Następnie wszystkie komunikaty Debug.Assert/Fail są przesyłane do karty wyjściowej tekstu NUnit, bez wpływu na testy. – yoyo

+0

Aktualizacja dla NUnit 3.0: [SetupFixture] powoduje konflikt z [SetUp] i [TearDown]. Ale to jest w porządku - wystarczy wstawić całą klasę, bez początkowego [SetUpFixture], w swoim TextFixture. Co więcej, zmień ustawienie [SetUp] na [OneTimeSetUp] (podobnie dla TearDown), a zamiennik zostanie tylko jeden raz! Działa to naprawdę słodko! – shipr

Powiązane problemy