Test basati sui dati con jUnit

Question

Cosa usi per scrivere test basati sui dati in jUnit?

(La mia definizione di) un test basato sui dati è un test che legge i dati da una fonte esterna (file, database, ...), esegue un test per riga / file / qualunque cosa e visualizza i risultati in un test corridore come se avessi prove separate: il risultato di ogni corsa viene visualizzato separatamente, non in un unico aggregato.

Answer 1

In JUnit4 è possibile utilizzare Parameterized testrunner per eseguire la guida dei dati test.

Non è terribilmente ben documentato, ma l'idea di base è quella di creare un metodo statico (annotato con @Parameters ) che restituisca una raccolta di matrici di oggetti. Ognuno di questi array viene utilizzato come argomento per il costruttore della classe di test, quindi i normali metodi di test possono essere eseguiti utilizzando i campi impostati nel costruttore.

Puoi scrivere codice per leggere e analizzare un file di testo esterno nel metodo @Parameters (o ottenere dati da un'altra fonte esterna), e quindi potresti aggiungere nuovi test modificando questo file senza ricompilare i test.

Answer 2

Qui è dove TestNG, con il suo @DataSource, brilla. Questo è uno dei motivi per cui lo preferisco a JUnit; gli altri sono dipendenze e test con thread paralleli.

Answer 3

Uso un database in memoria come hsqldb in modo da poter precompilare il database con un " ; produzione stile " set di dati oppure posso iniziare con un database hsqldb vuoto e popolarlo con le righe di cui ho bisogno per eseguire i miei test. Inoltre, scriverò i miei test usando JUnit e Mockito .

Answer 4

Uso la combinazione di dbUnit , jMock e jUnit 4. Quindi puoi etere eseguirlo come suite o separatamente

Answer 5

È meglio estendere TestCase con un " DataDrivenTestCase " adatto alle tue esigenze. Ecco un esempio funzionante: http://mrlalonde.blogspot.ca/2012/08 /data-driven-tests-with-junit.html

A differenza dei test con parametri, consente casi di test ben definiti.

Answer 6

Sto con @ DroidIn.net, è esattamente quello che sto facendo, tuttavia per rispondere alla tua domanda letteralmente "e visualizzare i risultati in un test runner come se avessi dei test separati". devi guardare il corridore con parametri JUnit4. DBUnit non lo fa. Se devi fare molto di questo, onestamente TestNG è più flessibile, ma puoi assolutamente farlo in JUnit.

Puoi anche guardare il runner di JUnit Theories, ma il mio ricordo è che non è eccezionale per i set di dati basati sui dati, il che ha senso perché JUnit non ha a che fare con grandi quantità di dati esterni.

Answer 7

Anche se questo è un argomento piuttosto vecchio, ho ancora pensato di contribuire con la mia condivisione. Ritengo che il supporto di JUnit per i test basati sui dati sia meno e troppo ostile. per es. per usare i parametri, dobbiamo scrivere il nostro costruttore. Con Theories runner non abbiamo il controllo sul set di dati di test che viene passato al metodo di test.

Ci sono più svantaggi identificati in questa serie di post di blog: http://www.kumaranuj.com/2012/08/junits-parameterized-runner-and-data.html

Ora esiste una soluzione completa che si presenta abbastanza bene sotto forma di EasyTest che è un framework esteso da JUnit e che ha lo scopo di fornire molte funzionalità ai suoi utenti. Il suo obiettivo principale è eseguire i test basati sui dati utilizzando JUnit, sebbene non sia più necessario dipendere effettivamente da JUnit. Ecco il progetto github per refernece: https://github.com/anujgandharv/easytest

Se qualcuno è interessato a contribuire con i propri pensieri / codice / suggerimenti, questo è il momento. Puoi semplicemente andare al repository github e creare problemi.

Answer 8

In genere i test basati sui dati utilizzano un piccolo componente testabile per gestire i dati. (Oggetto di lettura file o oggetti simulati) Per database e risorse al di fuori dell'applicazione, i simulazioni vengono utilizzati per simulare altri sistemi. (Servizi Web e database ecc.). In genere vedo che ci sono file di dati esterni che gestiscono i dati e l'output. In questo modo il file di dati può essere aggiunto al VCS.

Answer 9

Al momento abbiamo un file props con i nostri numeri ID al suo interno. Questo è orribilmente fragile, ma è facile ottenere qualcosa da fare. Il nostro piano è di avere inizialmente questi numeri ID sovrascrivibili dalle proprietà -D nelle nostre formiche.

Il nostro ambiente utilizza un DB legacy con dati orribilmente intrecciati che non è caricabile prima di un'esecuzione (ad es. con dbUnit). Alla fine vorremmo arrivare al punto in cui un test di unità interrogherebbe il DB per trovare un ID con la proprietà sotto test, quindi utilizzarlo nel test di unità. Sarebbe lento ed è più propriamente chiamato test di integrazione, non "test unitari", ma testeremo dati reali per evitare la situazione in cui la nostra app funziona perfettamente con dati test ma fallisce con dati reali.

Answer 10

Alcuni test si presteranno ad essere guidati dall'interfaccia.

Se le letture del database / file vengono recuperate da una chiamata di interfaccia, è sufficiente ottenere l'unità di test per implementare l'interfaccia e la classe di test dell'unità può restituire tutti i dati desiderati.