Devo usare try catch nei miei metodi di prova?

18

Sto facendo dei test unitari.

Sto provando a testare una funzione.

Lo chiamo dal mio componente di test. Ma se la funzione remota non è in grado di gestire l'eccezione, anche il mio componente tester otterrà un'eccezione, immagino.

Quindi dovrei preoccuparmi di ottenere un'eccezione nel mio componente tester?

Grazie.

MODIFICARE:

PS:

Lanciare un errore è buono, ma solo per altre funzioni, non per gli utenti finali fino alla sua ultima opzione!

OMG ho scritto un preventivo di programmazione !!

testing unit-testing exceptions

— Vikas
fonte

Sono nuovo ai test e dovrei testare solo il comportamento della funzione. Penso che si chiama test blackbox e whitebox. Oh me lo ricordo. L'ho studiato al college!

— Vikas,

Quale lingua e framework xUnit stai usando in modo specifico? Direi di sì in alcuni casi.

— Greg K,

Sto usando MXUnit con MockBox e ColdBox per il linguaggio ColdFusion.

— Vikas,

23

Risposta breve: NO.

Non catturare eccezioni nei test unitari. Stai testando l'unità per trovare errori e situazioni in cui vengono sollevate eccezioni.

Il framework di unit test dovrebbe gestire le eccezioni in modo sano. La maggior parte (se non tutti) i framework xUnit hanno un costrutto per aspettarsi certe eccezioni che usi quando vuoi indurre una particolare condizione di eccezione nel sistema sotto test e hai un test pass se l'eccezione prevista viene sollevata ma fallisce se non lo fa.

— mcottle
fonte

Penso che il framework di test avanzato sia in grado di gestire molto bene le eccezioni, anche se trovo che in Visual Studio possiamo testare eccezioni come hai detto "eccezione prevista". Quindi è bello sapere e condividere. Grazie ..

— Vikas,

A volte, vuoi verificare se viene generata un'eccezione, perché un buon test non verifica solo i casi in cui le cose funzionano, ma anche i casi in cui falliscono.

— deadalnix,

1

Vuoi catturare le eccezioni, come vuoi testare le situazioni in cui si verificano le eccezioni (in particolare le tue eccezioni). Se si scrive codice progettato per fallire con un'eccezione in determinate condizioni, tali condizioni dovrebbero far parte della suite di test e quindi dovrebbero essere testate. Nell'ambito di tali test, tali eccezioni dovrebbero essere individuate e analizzate.

— jwenting

1

@Jwenting Leggi il secondo paragrafo - I framework di unit test raccolgono le eccezioni e consentono il superamento dei test se alcune eccezioni vengono sollevate e falliscono se non lo sono

— mcottle

5

(Contrariamente alla risposta di mcottle) Risposta lunga: NO ... il più delle volte

Quando dici che ti aspetti che un test sollevi una particolare eccezione, saprai quando QUALSIASI linea in quel test solleva quella particolare eccezione.

Non è esattamente la stessa cosa che sapere che il metodo sotto test genera l'eccezione.

Se il test prevede l'impostazione di un oggetto o di un contesto (all'interno del test, non nella versione del framework di SetUp), potrebbe essere meglio racchiudere la singola riga che si desidera effettivamente testare in un tentativo / cattura, possibilmente con un helper.

Per esempio,

public static class AssertHelper {
    public delegate void Thunk();

    public static void DoesNotThrow<T>(Thunk thunk, string message = "")
        where T: Exception {
        try {
            thunk.Invoke();
        } catch(T) {
            Assert.Fail(message);
        }
    }
}

e poi

[TestMethod]
public void assertHelperInAction() {
    // Random setup stuff here that's too annoying to put in my SetUp
    // method.
    AssertHelper.DoesNotThrow<IllegalArgumentException>(() =>
        {/* My random method under test */})
}

Se questo test fallisce, so che il mio metodo sotto test ha generato l'eccezione e non qualcosa nella configurazione casuale.

(Dovresti cercare di evitare roba di installazione casuale. A volte, è più facile avere un codice di installazione nel test.)

— Frank Shearar
fonte

Buon esempio! Cerco di stare molto attento a limitare la fase di "test" solo al test preciso, ma ricorderò questo trucco per quando non riesco proprio a trovare un modo per farlo (ad esempio, quando testare una condizione di gara e serve 'setup' vicino al 'test' per raggiungere la condizione).

— Ethel Evans,

1

In generale, dovresti semplicemente rilasciare l'eccezione e il framework di test ti fornirà un bel rapporto con tutte le informazioni di cui hai bisogno.

Ma nella metodologia TDD, ci si aspetta che segua questi passaggi:

Scrivi un test
Guardalo fallire e rendi comprensibile l'errore
Correggere il codice
Rifattorizzare il codice e il test

Quando si fa uscire un'eccezione, se l'errore è chiaro, va bene. Ma a volte l'eccezione è oscura o addirittura fuorviante. Come hai potuto lasciare che fosse nel tuo codice (per te in seguito, quando l'avrai dimenticato, o per un membro del team che perderà alla grande la risoluzione del problema)? Quindi la mia politica è: " Se è necessario chiarire un errore, è necessario cogliere l'eccezione ".

— KLE
fonte