Test e Mock classes, mi aiutate a capire?
Uno qualunque
Mi stavo documentando sulla programmazione orientata ai test, tirando
giￜ qualche progetto open source Java mi sono imbattuto nei test
effettuati con l'ausilio di "mock classes". Mi sono informato e credo di
aver capito cosa sono, solo che non ho capito bene il senso. Che senso
ha testare del codice usando delle classi a cui fai ritornare quello che
vuoi? Non ￜ in questo modo un "truccare" i test?
Cosa mi sfugge...?
equinozio
ngw
> x-post
>
> Mi stavo documentando sulla programmazione orientata ai test, tirando
> giů qualche progetto open source Java mi sono imbattuto nei test
> effettuati con l'ausilio di "mock classes". Mi sono informato e credo
> di aver capito cosa sono, solo che non ho capito bene il senso. Che
> senso ha testare del codice usando delle classi a cui fai ritornare
> quello che vuoi? Non č in questo modo un "truccare" i test?
>
> Cosa mi sfugge...?
Mock e stub servono principalmente per testare l'interazione tra
classi, ovvero che alla determinata condizione venga chiamato il
determinato metodo con i determinati argomenti.
In un sistema MVC, per esempio, la maggior parte dei mock e degli stub
avvengono a livello del controller, mentre fixtures e/o dati veri
vengono usati nei modelli.
ngw
--
Nicholas Wieland (ngw)
Zooppa CTO
911 Western Avenue, Suite 420
Seattle, WA 98104 US
Dimitri De Franciscis
>
> Cosa mi sfugge...?
>
La ragione principale è che in questo modo puoi testare in maniera molto
semplice e veloce uno strato applicativo che di solito ha bisogno di
molte "sovrastrutture". Ad esempio questa tecnica è molto usata per
testare servlet o comunque controller di framework web, che rispondono a
richieste http. Con i mock objects puoi creare al volo delle richieste
http "fasulle", che ti permettono di testare i tuoi componenti senza
dover ogni volta configurare e far partire un servlet engine. Stessa
cosa per EJB, message queue, interazione col DB, ecc.
Esempio di "vita reale":
Arriva un progetto di quelli che già in partenza sono "da consegnare il
mese scorso" (?). In quattro e quattr'otto preparo delle interfacce dei
servizi di base e una configurazione dell'applicazione, ma mi rendo
conto che da solo non ce la farò mai. Fortunatamente mi assegnano uno
dei "pupilli", che non conosce una mazza di JDBC e/o Hibernate, però ha
già sviluppato per web e conosce qualcosa di MVC; allora gli dico
testuali parole: "Tu implementa questi servizi alla caxxo e usali nei
controller come se fossero veri, alle query 'vere' ci penso io".
Insomma, mentre lui si divertiva a fare il frontend sfruttando dei
servizi "mock", io implementavo i servizi "veri". In questo modo al
momento dell'integrazione non ci sono stati molti problemi, e siamo
riusciti a ridurre di 1/3 i tempi inizialmente previsti :)
--
Dimitri De Franciscis
Phone: (+39) 3401570778
Website: http://www.megadix.it/
rootkit
> Mi stavo documentando sulla programmazione orientata ai test, tirando
> gi qualche progetto open source Java mi sono imbattuto nei test
> effettuati con l'ausilio di "mock classes". Mi sono informato e credo di
> aver capito cosa sono, solo che non ho capito bene il senso. Che senso
> ha testare del codice usando delle classi a cui fai ritornare quello che
> vuoi? Non in questo modo un "truccare" i test?
è un concetto alla base dello "unit testing".
se stai scrivendo uno unit test per la classe "a" è fondamentale che
sul test non vadano ad influire le collaborazioni della classe "b" che
non vanno testate in quell'ambito. quindi nel momento in cui trovi una
collaborazione le mock classes intervengono affinché tu la possa
"simulare" tale collaborazione. naturalmente poi avrai lo unit test
per la classe "b" separato e indipendente.
il limite che in qualche modo hai intuito è che la collaborazione di
"b" con "a" ti rimane non testata. infatti gli unit test non hanno la
presunzione di essere esaustivi e non escludono la necessità di fare
il test di integrazione.
ispas
> il limite che in qualche modo hai intuito è che la collaborazione di
> "b" con "a" ti rimane non testata. infatti gli unit test non hanno la
> presunzione di essere esaustivi e non escludono la necessità di fare
> il test di integrazione.
Direi che c'è un altro limite bello grosso. Queste classi mock, stub
od altro sono pur sempre codice che viene scritto e può essere errato
tanto quanto le classi "vere".
Pertanto chi controlla i controllori? Ovvero, chi verifica che le
classi di test/mock/stub producano i corretti "stimoli" per la classe
sotto test?
rootkit
> Direi che c'è un altro limite bello grosso. Queste classi mock, stub
> od altro sono pur sempre codice che viene scritto e può essere errato
> tanto quanto le classi "vere".
> Pertanto chi controlla i controllori? Ovvero, chi verifica che le
> classi di test/mock/stub producano i corretti "stimoli" per la classe
> sotto test?
no, non funziona così. le mock classes non devono (ovviamente) essere
riscritte. in java ci sono framework che ti consentono all'interno del
test di definire con una sorta di "metalinguaggio" le le cosiddette
"expectations", ovvero i metodi che ci si aspetta vengano invocati, i
parametri attesi e valori di ritorno. quindi semplicemente sta a chi
scrive il test fare in modo che queste classi producano i corretti
stimoli.