Attualmente stiamo scrivendo casi di unit test nel nostro progetto. Le implementazioni per i metodi di database esistono e funziona bene. In questo caso, perché dobbiamo scrivere oggetti finti? C'è qualche motivo specifico? Perché non riesco a testare direttamente l'implementazione DAO?
Risposte:
Non dovresti deridere le chiamate al database perché ciò vanificherebbe lo scopo. Ciò che DOVREBBE deridere sono, ad esempio, le chiamate al tuo DAO, ad esempio, da un livello di servizio. Il derisione ti consente di testare i metodi in modo isolato.
Supponi di avere una simulazione di un ristorante con un'architettura come questa:
Cook <=> Server <=> Customer
Vuoi testare ogni strato in modo indipendente. Qui Serverè il tuo livello di servizio e Cookpuò essere pensato come un DAO. Il Serverè ciò che si vuole prendere in giro durante il test Customer, e Cookè quello che si vuole finto durante il test del Server. I Cooktest unitari, tuttavia, dovrebbero verificare che l'implementazione stia restituendo un hamburger quando è stato ordinato un hamburger e non una gomma.
È perfettamente ok testare businesslogic insieme al database. ma questi test vengono chiamati test di integrazione anche se si utilizzano nunit o junit o phpunit per eseguirli.
Gli unittest sono test spezializzati in cui i test in isolamento (vale a dire buisinesslogic senza il database) sono importanti. Derisioni / falsi / stups sono usati per imporre questo isolamento.
Semplicemente: per testare il DAO effettivo e non il contenuto del database.
Supponiamo che la tua classe DAO Person abbia un metodo getByName (). Scrivi un test e chiami Person.getByName ("John Smith"). Supponiamo che il test fallisca, perché qualcuno ha rimosso il record di John dal database. Ora, ogni software CI e i vostri supervisori / revisori possono affermare che il vostro software è difettoso, mentre in realtà non lo è. Se deridi DB, puoi provare che il tuo DAO funziona se viene fornita la riga corretta dalla tabella corretta.
Se vuoi davvero testare il database stesso, cioè: se l'esecuzione di un determinato metodo DAO mette i dati in un certo stato, allora è anche possibile. Inoltre, è davvero utile con modelli di dati stravaganti (EAV, set di alberi nidificati) in cui non ci si può aspettare che il database fornisca integrità a prova di proiettile. Dai un'occhiata a DBUnit per semplificarti la vita.
Un altro motivo è evitare i tempi di esecuzione dell'esecuzione effettiva dei comandi del database. Potrebbe non sembrare molto, ma il sovraccarico di impostazione e smantellamento delle connessioni alla fine si sommerà e molto probabilmente aumenterà in modo significativo il tempo complessivo di esecuzione della suite di test rispetto all'utilizzo di oggetti finti.
Per isolare la classe che stai testando. Altrimenti se il test fallisce come fai a sapere se il problema è nella classe che stai testando o in una delle sue dipendenze.