JUnit per il codice del database

Question

Ho provato a implementare i test unitari e attualmente ho del codice che esegue quanto segue:

1. interrogare il database esterno, caricando in una tabella di alimentazione
2. query una vista, che è un delta delle mie tabelle di feed e dati, aggiornando la tabella di dati per abbinare la tabella dei feed

la mia strategia di test unitario è questa:

Ho un database di test che sono libero di manipolare.

1. in setUP(), carica alcuni dati nel mio database di test
2. esegui il mio codice, utilizzando il mio database di test come sorgente
3. ispezionare la tabella dati, verificando i conteggi e l'esistenza/non esistenza di determinati record
4. cancella il database di test, caricando un diverso set di dati
5. eseguire nuovamente il codice
6. ispezionare nuovamente la tabella dati

Ovviamente ho i set di dati che carico nel db di origine impostati in modo tale da sapere che determinati record dovrebbero essere aggiunti, eliminati, aggiornati, ecc.

Sembra che sia un po' complicato e dovrebbe esserci un modo più semplice?eventuali suggerimenti?

Answer 1

È tuo intento testare la vista che genera i delta o verificare che il tuo codice aggiunga, elimini e si aggiorni correttamente in risposta alla vista?

Se vuoi testare la vista, puoi usare uno strumento come DBUnit per popolare il tuo feed e le tabelle di dati con vari dati di cui hai calcolato manualmente il delta.Quindi, per ogni test dovresti verificare che la vista restituisca un insieme corrispondente.

Se vuoi testare come il tuo codice risponde alle differenze rilevate dalla vista, proverei ad astrarre l'accesso al database.Immagino un metodo Java al quale è possibile passare un set di risultati (o un elenco di POJO/DTO) e restituire un elenco di array di oggetti di parametri (di nuovo o POJO) da aggiungere.Altri metodi analizzerebbero l'elenco delle differenze per gli elementi da rimuovere e aggiornare.È quindi possibile creare un set di risultati fittizi o pojo, passarli al codice e verificare che vengano restituiti i parametri corretti.Il tutto senza toccare un database.

Penso che la chiave sia suddividere il processo in parti e testare ciascuna di esse nel modo più indipendente possibile.

Answer 2

DbUnit soddisferà le tue esigenze.Una cosa a cui prestare attenzione è che sono passati all'utilizzo di SLF4J come facciata di registrazione anziché JCL.Puoi configurare SLF4J per inoltrare la registrazione a JCL ma tieni presente che se stai utilizzando Maven DbUnit fa schifo nel loro provider di log Nop per impostazione predefinita, quindi dovrai utilizzare un'esclusione, io bloggato riguardo a questo conflitto di recente.

Answer 3

Utilizzo DbUnit, ma lavoro anche molto duramente per non dover eseguire test rispetto al DB.I test che vanno contro il database dovrebbero esistere solo allo scopo di testare l'interfaccia del database.Quindi ho Mock Db Connections che posso impostare i dati da utilizzare in tutto il resto dei miei test.

Answer 4

A parte il già suggerito DBUnit, potresti voler esaminare Unitil.Utilizza DBUnit, ma fornisce molto di più (citando dal sito):

• Manutenzione automatica dei database, con supporto per script incrementali, ripetibili e post elaborazione
• Disabilita automaticamente i vincoli e imposta le sequenze su un valore minimo
• Supporto per Oracle, Hsqldb, MySql, DB2, Postgresql, MsSql e Derby
• Semplifica la configurazione della connessione al database di test
• Inserimento semplice dei dati di test con DBUnit * Esegui test in una transazione
• Creazione e iniezione di JPA Entity Manager per la creazione e la sessione di Hibernate, TopLink e * Hibernate SessionFactory
• Test automaticamente la mappatura di entità JPA / oggetti mappati in ibernazione con il database

Answer 5

Se stai usando Maven, un'opzione è usare il file plugin-sql-maven.Consente di eseguire script di inizializzazione/popolamento del database durante il ciclo di creazione di Maven.