Come dovrei prendere in giro i test di un'applicazione con livello di servizio e livello DAO?

Parlerò di Test Doubles, se non si è imbattuto in questo termine, probabilmente si vorrà leggere L'articolo di Martin Fowler collega per primo.

• Per il test del database: se stai seguendo un approccio di testing dell'unità pure , utilizzerai uno stub o Mock tipo di Test Double per deridere la connessione DB e le sue risposte. Se stai usando un Mock , ti consiglio di utilizzare Mockito, JMock o il tuo altro strumento di simulazione preferito. Tuttavia, questo è abbastanza laborioso quando si tratta di testare una grande risorsa di terze parti come un database.

• Per il test del database - Se stai seguendo una definizione un po 'più libera di test delle unità, allora potresti usare un doppio di prova falso . Nel tuo caso particolare, questo sarebbe un database in memoria come HSQL. Questo è un modo molto popolare di "unità" per testare il livello del tuo database. Alcuni sosterranno che questo non è un test unitario e che è invece il test di integrazione. Penso che sia in realtà OK - il fatto è che hai qualche test che esalta il tuo codice: -)

• Per il test della cache: uno stile Stub di Test Double è probabilmente tuo amico qui, a seconda di quanto sia complessa l'API della cache.

HTH!

In astratto la risposta è abbastanza semplice.

Hai tre livelli.

[Il test case] - > [Il comportamento sotto test] - > [I collaboratori utilizzati da quel comportamento]

Il terzo livello è ciò che dovrebbe essere deriso. Ad esempio:

1. il PokemonCaptureServiceTest ;
2. test PokemonCaptureService ;
3. che utilizza Pokeball

In questo esempio risulta che Pokeball è una logica di terze parti. Richiede tutti i tipi di condutture idrauliche come connessioni al database e file di proprietà, ecc. Confidi che la tua terza parte lo abbia testato in modo appropriato, quindi vorresti ometterlo dal test di PokemonCaptureService . Quindi dovrebbe essere deriso.

Tuttavia, in un altro momento e luogo, il collaboratore Pokeball è una classe semplice che introduce una minima complessità nel caso di test e può essere facilmente inclusa nel test. In questo caso puoi decidere di includere un'istanza reale di Pokeball nell'istanza PokemonCaptureService in fase di test.

Non esiste una regola dura e veloce. Spetta a te progettare i test nel modo che ti sembra più adatto. Il tuo obiettivo è quello di creare test corretti e manutenibili il più rapidamente possibile. L'esperienza è la chiave qui. Scrivi altri test e amp; presto otterrai una buona intuizione per questo.

È difficile dire cosa esattamente vuoi testare, perché a giudicare dalla domanda ti trovi dappertutto. Quindi è difficile darti qualche esempio pratico su come procedere oltre a portarti ad articoli su come prendere in giro cose. Quindi devi essere più specifico e dividere un po 'le cose:

• Vuoi testare in modo che la cache funzioni correttamente?

• Vuoi testare alcune chiamate DB in particolare?

• Vuoi testare l'app in modo che stia utilizzando correttamente la cache?

Una volta che hai deciso esattamente cosa l'unità è che vuoi testare, allora selezionare cosa deridere diventa facile: in un puro test unitario, tutto tranne l'unità sotto test deve essere deriso. La logica alla base di questo è che puoi essere sicuro dalle tue aspettative di impostazione sui mock che l'unità testata funziona come dovrebbe.

Oltre a questo, potresti voler scrivere alcuni test in JUnit che sono test di integrazione, cioè usa meno mock. Anche se vengono utilizzati come controlli di integrità per vedere se il design del software è corretto, devi essere consapevole del fatto che saranno fragili e non forniranno mai alcun indicatore su cosa sia esattamente sbagliato nell'app o nel sistema.