NUnit-sprzątanie po niepowodzeniu testu

Od wersji 2.5.7, NUnit pozwala Tearddown wykryć, czy ostatni test nie powiódł się. Nowa klasa TestContext umożliwia testom dostęp do informacji o sobie łącznie z Teststautami.

Aby uzyskać więcej informacji, zapoznaj się z http://nunit.org/?p=releaseNotes&r=2.5.7

[TearDown]
public void TearDown()
{
    if (TestContext.CurrentContext.Result.Status == TestStatus.Failed)
    {
        PerformCleanUpFromTest();
    }
}

Chociaż możliwe jest zmuszenie do tego nUnit, nie jest to najbardziej rozsądny projekt, zawsze możesz ustawić gdzieś plik tymczasowy i jeśli ten plik istnieje, Uruchom oczyszczanie.

Zalecałbym zmianę kodu tak, aby włączyć transakcje bazodanowe i po zakończeniu testu po prostu przywrócić bazę danych do stanu pierwotnego (np. odrzucić transakcję, która reprezentuje twoje testy jednostkowe).

Tak, jest. Możesz użyć teardown atrybut , który będzie teardown po każdym teście. Chciałbyś zastosować ten skrypt "reset" bazy danych, który masz i oddzielić i ponownie skonfigurować przed i po każdym teście.

Ten atrybut jest używany wewnątrz TestFixture, aby zapewnić wspólny zestaw funkcje, które są wykonywane po każda metoda badania jest uruchamiana.

Update : na podstawie komentarzy i aktualizacji do pytania, powiedziałbym, że można użyć atrybut teardown i użyj zmiennych prywatnych, aby wskazać, czy zawartość metody powinna zostać uruchomiona.

Chociaż zauważyłem również, że nie chcesz żadnej skomplikowanej logiki lub kodu obsługi błędów.

Biorąc to pod uwagę, myślę, że standardowa konfiguracja / Teardown będzie dla Ciebie najlepsza. Nie ma znaczenia, czy jest błąd i nie musisz mieć żadnego kodu obsługi błędów.

Jeśli potrzebujesz specjalnego czyszczenia, ponieważ kolejne testy zależą od pomyślnego ukończenia obecny test, sugerowałbym ponowne sprawdzenie Twoich testów. prawdopodobnie nie powinny od siebie zależeć.

A co powiesz na użycie bloku Try-Catch, ponowne rozważenie złapanego wyjątku?

try
{
//Some assertion
}
catch
{
     CleanUpMethod();
     throw;
}

Chciałbym zrobić jak phsr sugeruje teraz i kiedy można sobie na to pozwolić, refaktor testów tak, że nigdy nie muszą polegać na tych samych danych, że inny test potrzebuje lub nawet lepiej abstrakcyjne warstwy dostępu do danych i wyśmiewają wyniki pochodzące z tej bazy danych. Wygląda na to, że twoje testy są dość drogie i powinieneś wykonać całą logikę zapytań w bazie danych i logikę biznesową w swoim zestawieniu nie obchodzi cię, jakie są wyniki, które są zwracane.

Będziesz także mógł przetestuj swoją wyjątkowość o wiele lepiej.

Inną opcją jest posiadanie specjalnej funkcji, która wyrzuci wyjątki, która ustawia przełącznik w ustawieniu testowym, który mówi o wystąpieniu wyjątku.

public abstract class CleanOnErrorFixture
{
     protected bool threwException = false;

     protected void ThrowException(Exception someException)
     {
         threwException = true;
         throw someException;
     }

     protected bool HasTestFailed()
     {
          if(threwException)
          {
               threwException = false; //So that this is reset after each teardown
               return true;
          }
          return false;
     }
}

Następnie użyj swojego przykładu:

[TestFixture]
public class SomeFixture : CleanOnErrorFixture
{
    [Test]
    public void MyFailTest()
    {
        ThrowException(new InvalidOperationException());
    }

    [Test]
    public void MySuccessTest()
    {
        Assert.That(true, Is.True);
    }

    [TearDown]
    public void CleanUpOnError()
    {
        if (HasLastTestFailed()) CleanUpDatabase();
    }
}

Jedynym problemem jest to, że ślad stosu doprowadzi do CleanOnErrorFixture

Jedną z opcji, o której dotąd nie wspomniano, jest zawinięcie testu w obiekt TransactionScope, więc nie ma znaczenia, co się stanie, ponieważ test nigdy niczego nie zobowiązuje do DB.

Oto kilka szczegółów na temat techniki . Prawdopodobnie możesz znaleźć więcej, jeśli wykonasz wyszukiwanie w testach jednostkowych i transactionscope(chociaż naprawdę robisz testy integracyjne, jeśli trafisz na DB). Używałem go z powodzeniem w przeszłości.

Takie podejście jest proste, nie wymaga żadnego czyszczenia i zapewnia te testy są izolowane.

Edit-właśnie zauważyłem, że odpowiedź Raya Hayesa jest również podobna do mojej.

Jak to się nie udaje? Czy można umieścić go w try ( do test) / catch (fix broken db) / finally block?

LUB możesz wywołać prywatną metodę, aby ją naprawić, gdy sprawdzisz swój stan fail.

Nie mówię, że to świetny pomysł, ale powinien zadziałać. Pamiętaj, że awarie twierdzeń są tylko wyjątkami. Nie zapominaj również, że istnieje również atrybut [TestFixtureTearDown], który uruchamia się tylko raz po uruchomieniu wszystkich testów w urządzeniu.

Używając tych dwóch faktów można napisać coś w rodzaju ustawienia flagi, jeśli testy nie powiodły się i sprawdzenia wartości flagi w urządzeniu testowym.

[TestFixture]
public class Tests {
     private bool testsFailed = false;

     [Test]
     public void ATest() {
         try {
             DoSomething();
             Assert.AreEqual(....);
         } catch {
            testFailed = true;
         }
     }

     [TestFixtureTearDown]
     public void CleanUp() {
          if (testsFailed) {
              DoCleanup();
          }
     }
}

Możesz dodać metodę [TearDown] z
if (TestContext.CurrentContext.Result.Status != TestStatus.Passed)
jakiś kod do wykonania w przypadku niepowodzenia testu.