Mi chiedo, qual è il modo migliore per testare i metodi relativi a JDBC? Come ad esempio l'aggiunta di utenti, il ban degli utenti, eccTest delle query JDBC in JUnit
(utilizzando JUnit)
Devo impostare tutti i miei metodi void Per booleani e li restituisce true se hanno lavorato, false se non lo facessero, e asserire tali valori di conseguenza nei miei test JUnit?
Questa è solo una domanda generica per trovare le migliori pratiche.
Grazie!
Personalmente trovo che uno strumento fantastico sia Mockito. Puoi prendere in giro ciò che un ritorno JDBC ti darebbe in modo che tu possa dire dato una query e un parametro specifici, otterresti un valore specifico indietro.
Non dovresti modificare il codice per farlo funzionare con i test di unità, dovrebbe funzionare sia in produzione che in test esattamente nello stesso modo.
Si potrebbe anche considerare l'utilizzo di un database in memoria come Derby e il caricamento dei valori all'inizio della fase di test in modo da conoscere i valori che esistono in esso. Mocking sarebbe probabilmente più veloce in termini di tempo di esecuzione.
Okay, proverò Mockito, grazie! – user2297666
Se lo fai, NON testerai il codice del tuo database: testerai tutte le cose che dipendono dal codice del tuo Database, ma non dal codice stesso del DB.E 'questo quello che vuoi fare? – DaveH
L'accesso al database in un test di unità non è generalmente una buona idea. Penso che sarebbe meglio deridere la connessione al database e controllare se vengono chiamate le query corrette. Di causa che non include il caso in cui il database è cambiato e le query non funzionano più, ma che normalmente accade molto raramente.
Penso che i metodi CRUD molto semplici non richiedano il test dell'unità. Basta eseguire il metodo e quindi controllare la tabella. Il test più complesso riguarderà le operazioni CRUD di base.
Tuttavia, ho già letto il codice in cui l'operazione Crea/Trova è stata testata in un metodo come un test di integrazione. Il risultato di find viene quindi confrontato con la richiesta di creazione.
EDIT: Si può anche guardare al DB Unit
Quando scrivo i test come questo che attribuisco al database effettivo che sarò in esecuzione contro la (piuttosto che un database in memoria). Gran parte del mio codice utilizza stored procedure o altre funzionalità specifiche del database che non sono necessariamente supportate da Derby, ecc.
Se questi sono test di unità o di integrazione, non lo so. Ma sono importanti, quindi preferisco averli integrati nel ciclo di Integrazione continua.
Se si utilizza un database persistente, si ha un paio di cose extra di cui preoccuparsi. È necessario conoscere lo stato dei dati prima dell'esecuzione dei test e si dovrebbe fare tutto il possibile per reinserire lo stato noto durante l'esecuzione di ogni test. Se non lo fai, i tuoi test non saranno indipendenti l'uno dall'altro e inizierai a trovare i test più tardi nella suite, iniziando a fallire a causa di errori nei test precedenti.
Generalmente ciò che consiglio è che questa è la provincia di un test di integrazione. Utilizzare un database in memoria come H2 al posto del normale database e affermare che dopo aver richiamato i metodi DAO che le tabelle contengono le righe previste. –