Attualmente stiamo scrivendo casi di test unitari nel nostro progetto. Le implementazioni per i metodi di database esistono e funzionano bene. In questo caso, perché abbiamo bisogno di scrivere oggetti finti? C'è qualche ragione specifica? Perché non posso testare direttamente l'implementazione di DAO?
Non dovresti prendere in giro le chiamate al database perché ciò potrebbe vanificare lo scopo. Ad esempio, è necessario chiamare il tuo DAO, ad esempio, da un livello di servizio. Mocking ti permette di testare i metodi separatamente.
Supponiamo di avere una simulazione di ristorante con un'architettura simile a questa:
Cook <=> Server <=> Customer
Vuoi testare ogni livello in modo indipendente. Qui Server è il tuo livello di servizio e Cook può essere considerato come un DAO. Il Server è ciò che vuoi fare finta di testare Customer , e Cook è ciò che vuoi fare finta testando il Server . I test dell'unità Cook , tuttavia, dovrebbero verificare che l'implementazione restituisca un hamburger quando è stato ordinato un hamburger e non un pneumatico di gomma.
È perfettamente ok testare businesslogic insieme al database. ma questi test sono chiamati test di integrazione anche se usi nunit o junit o phpunit per eseguirli.
Unittests sono test spezializzati in cui la verifica in isolamento (ad esempio buisinesslogic senza il database) è importante. Mazze / falsi / stupidi sono usati per rafforzare questo isolamento.
Un altro motivo è evitare il tempo di esecuzione dei comandi del database. Potrebbe non sembrare molto, ma alla fine il sovraccarico di installazione e interruzione delle connessioni si sommerà e molto probabilmente aumenterà significativamente il tempo complessivo per eseguire la suite di test rispetto all'uso di oggetti mock.
Semplicemente: per testare l'effettivo DAO e non il contenuto del database.
Supponi 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 prendi in giro DB, puoi provare che il tuo DAO funziona se viene data una riga corretta dalla tabella corretta.
Se vuoi veramente testare il database stesso, cioè: se l'esecuzione di un determinato metodo DAO mette i dati in un certo stato, allora è anche possibile. Inoltre, è molto utile con modelli di dati stravaganti (EAV, set di strutture nidificate) 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.
Per isolare la classe che stai testando. Oppure se il test fallisce come sai che il problema è nella classe che stai testando o in una delle sue dipendenze.
Leggi altre domande sui tag unit-testing