Come si ignora un test basato su un altro test in NUnit?

Question

Sto scrivendo alcuni test NUnit per le operazioni di database. Ovviamente, se Add() fallisce, allora anche Get() avrà esito negativo. Tuttavia, sembra ingannevole quando entrambi gli errori Add() e Get() falliscono perché sembra che ci siano due problemi invece di uno solo.

Esiste un modo per specificare un 'ordine' per le prove per l'esecuzione in, nel senso che se il primo test ha esito negativo, i seguenti test vengono ignorati?

Nella stessa riga, c'è un modo per ordinare le classi di test dell'unità? Ad esempio, vorrei eseguire i miei test per le operazioni di base del database prima dei test per i dati round-trip dall'interfaccia utente.

Nota: Questo è un po 'diverso che avere le prove dipendono l'uno dall'altro, è più come far sì che qualcosa funziona prima prima di eseguire una serie di test. È una perdita di tempo, ad esempio, eseguire una serie di operazioni di database se non è possibile ottenere una connessione al database in primo luogo.

Modifica: Sembra che ad alcune persone manchi il punto. Non sto facendo questo:

[Test] 
public void AddTest() 
{ 
    db.Add(someData); 
} 

[Test] 
public void GetTest() 
{ 
    db.Get(someData); 
    Assert.That(data was retrieved successfully); 
} 

Piuttosto, sto facendo questo:

[Test] 
public void AddTest() 
{ 
    db.Add(someData); 
} 

[Test] 
public void GetTest() 
{ 
    // need some way here to ensure that db.Add() can actually be performed successfully 
    db.Add(someData); 
    db.Get(somedata); 
    Assert.That(data was retrieved successfully); 
} 

In altre parole, voglio garantire che i dati possono essere aggiunti in primo luogo prima che io possa verificare se può essere recuperato. Si presume che io stia utilizzando i dati del primo test per passare il secondo test quando non è così. Sto cercando di assicurarmi che una sola operazione sia possibile prima di tentarne un'altra che dipende da essa.

Come ho detto già, è necessario assicurarsi che si può ottenere una connessione al database prima di eseguire operazioni di database. O che puoi aprire un file prima di eseguire operazioni sui file. Oppure connettiti a un server prima di testare le chiamate API. O ... hai capito il punto.

Answer 1

creare una variabile globale e viceversa sia di prova per Get a meno Add Impostare a true (fare questo nell'ultima riga di Add):

public boolean addFailed = false; 
public void testAdd() { 
    try { 
     ... old test code ... 
    } catch (Throwable t) { // Catch all errors 
     addFailed = true; 
     throw t; // Don't forget to rethrow 
    } 
} 
public void testGet() { 
    if (addFailed) return; 
    ... old test code ... 
} 

Answer 2

non credo che sia possibile out-of scatola.

In ogni caso, la classe di progettazione prova come descritto renderà il codice di prova molto fragile.

Answer 3

MbUnit sembra avere un DependsOnAttribute che ti consentirebbe di fare ciò che vuoi.

Se l'altro dispositivo di prova o con un metodo non riesce allora questa prova non corsa. Inoltre, la dipendenza forza questo test per eseguirsi dopo quelli da da cui dipende .

Non so nulla di NUnit però.

Answer 4

NUnit supporta una "Assume.That" sintassi per setup.This convalida è documentata come parte del Theory (grazie clairestreb).Nello spazio dei nomi NUnit.Framework è una classe Assume. Per citare la documentazione:

/// Provides static methods to express the assumptions 
/// that must be met for a test to give a meaningful 
/// result. If an assumption is not met, the test 
/// should produce an inconclusive result. 

Quindi, nel contesto:

public void TestGet() { 
    MyList sut = new MyList() 
    Object expecting = new Object(); 
    sut.Put(expecting); 
    Assume.That(sut.size(), Is(1)); 
    Assert.That(sut.Get(), Is(expecting)); 
} 

Answer 5

I test dovrebbero mai dipendono l'uno dall'altro. Hai appena scoperto perché. I test che dipendono l'uno dall'altro sono fragili per definizione. Se sono necessari i dati nel DB per il test per Get(), inserirli nel passaggio di installazione.

Answer 6

Penso che il problema è che stai usando NUnit per eseguire qualcosa di diverso dal tipo di test delle unità che NUnit è stato creato per funzionare.

In sostanza, si desidera che AddTest venga eseguito prima di GetTest e si desidera che NUnit interrompa l'esecuzione dei test in caso di errore di AddTest.

Il problema è che è antitetico al collaudo dell'unità - i test dovrebbero essere completamente indipendenti e funzionare in qualsiasi ordine.

Il concetto standard Unit Testing è che se si dispone di un test attorno alle funzionalità 'Aggiungi', quindi è possibile utilizzare il 'Aggiungi' funzionalità nel test 'Get' e non preoccuparsi di se 'Aggiungi' opera all'interno del 'Prendi' il test. Conosci i lavori "Aggiungi": ne hai una prova.

Il principio "PRIMO" (http://agileinaflash.blogspot.com/2009/02/first.html) descrive come devono comportarsi i test dell'unità. Il test che si desidera scrivere viola sia "I" (isolato) che "R" (ripetibile).

Se sei preoccupato che la connessione al database scenda tra i tuoi due test, ti consiglio che anziché collegarsi ad un vero database durante il test, il tuo codice dovrebbe usare una sorta di interfaccia dati, e per il test, dovresti usare un'interfaccia simulata. Se il punto del test è per esercitare la connessione al database, è possibile che si stia semplicemente utilizzando lo strumento sbagliato per il lavoro, che in realtà non è un test unitario.

Answer 7

Non è possibile assumere alcun ordine di esecuzione del test, pertanto è necessario verificare eventuali prerequisiti all'interno delle classi di test.

Segrega il test Aggiungi in una classe di test, ad es. Aggiungi test e inserisci i test Get in un'altra classe di test, ad es. classe GetTests.

Nel metodo [TestFixtureSetUp] della classe GetTests, verificare di disporre dell'accesso al database funzionante (ad esempio il lavoro di Add), e in caso contrario, Assert.Ignore o Inconcludente, come si ritiene opportuno.

Questo interromperà l'apparecchio di prova GetTests quando i suoi prerequisiti non saranno soddisfatti, e salterà cercando di eseguire uno dei test unitari in esso contenuti. (penso! Sono un principiante nUnit.)