2009-11-25 36 views
8

Voglio testare il mio programma (in C) perché conosco i vantaggi di farlo anche perché mostra dove si trova il problema.Test unitario - Come procedere?

Mi piace anche il test blackbox, poiché mi dice se il programma funziona (almeno per i test).

Al momento, sto utilizzando Autotest (che viene fornito con Autoconf) per non aggiungere una dipendenza.

A questo punto, non mi dispiacerebbe usare un framework migliore, ma il problema è che non voglio utilizzare un framework diverso per blackbox e unit test. Sarebbe possibile eseguire i test blackbox da un framework di test unitario? La cosa che mi piacerebbe davvero è una buona resa dei log, che dice esattamente cosa è andato storto e dove.

La mia altra opzione è test dell'unità con Autotest. Il problema è che non esiste un framework. Ho scritto un piccolo "test driver" che accetta il nome della funzione da testare e gli argomenti da passare alla funzione, e chiama quella funzione. Il problema è che non sono sicuro di quale limite utilizzare tra le asserzioni e di emettere il valore di ritorno della funzione (per scopi di registrazione, poiché mi piace come Autotest mi darà una diff). Poiché la maggior parte delle funzioni restituisce elenchi, è più rapido prepararsi utilizzando il diff con l'output previsto (expout utilizzando Autotest).

+0

In quale lingua è scritto il programma? – Mathias

+0

Eh, non posso credere di averlo dimenticato. È scritto in C. – alternative

+0

Se considererai altri framework, Wikipedia ha un elenco di framework di test unitari per C: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C C'è anche un prodotto chiamato autounit, che dovrebbe si integri bene con autoconf, attualmente beta. http://autounit.tigris.org/ http://autounit.tigris.org/files/documents/187/171/autounit.html –

risposta

2

sarebbe possibile eseguire i test Blackbox da una framework di unit test?

Sì, è possibile richiamare l'autotest con system() dai test di unità e quindi asserire sul valore restituito.

Ma io non consiglierei di farlo poiché i test di unità sono eseguiti molto spesso, devono essere molto veloci, cioè misurati in secondi, non in minuti.

unit test e test di integrazione (che si chiama test Blackbox) servono diversi scopi: test di unità verificare che i unità nel codice (qualunque cosa questo significa, funzione o gruppi di funzione) funziona come previsto dalle prove, mentre i test di integrazione coprono il programma end-to-end, convalidandolo nel suo complesso.

Quindi, in genere i test di unità vengono eseguiti dopo ogni modifica del codice, soprattutto se si applica TDD, mentre i test di integrazione vengono eseguiti quando è stata aggiunta una funzionalità.

Preferirei avere un programma di test unitario tipico, con asserzioni, e una suite di integrazione che invocherebbe i test unitari oltre ai test Blackbox.

Il problema è che io non sono sicuro di quello di confine da utilizzare tra affermazioni e l'output il valore di ritorno della funzione (a fini di registrazione, dal momento che mi piace come Autotest mi darà un diff).

Con affermazioni nulla consente uscita: valori sia attesi e reali sono uguali e non succede nulla, oppure sono diversi ei quadro stampe UT su un messaggio di errore (expected è X, reale è Y). Quello è uno lasciare che il computer faccia il lavoro di test.

Con il diff di output di registrazione, si deve ancora ispezionare manualmente (visivamente) il risultato del diff (ad esempio: c'è un elemento mancante nella lista o un elemento in più ...).

Poiché la maggior parte funzioni restituiscono liste, è più veloce di preparare usando il diff con uscita prevista (expout usando Autotest).

Si potrebbe desiderare di scrivere una funzione che confronta le liste usando affermazioni.

0

Si consiglia di utilizzare CTest, che viene fornito con CMake, un sistema make cross-piattaforma con molte backend: http://www.cmake.org/Wiki/CMake#CTest

PS: CMake è molto più potente di autotools troppo.

+0

Non sto usando CMake. – alternative

+0

Puoi prendere in considerazione un interruttore, fino a quando non è troppo tardi :-) – Flavius