Newsgroup: it.lavoro.informatica
Titolo: Test e Mock classes, mi aiutate a capire?

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...?

> Cosa mi sfugge...?
Wikipedia.
http://en.wikipedia.org/wiki/Mock_object
Paragrafo : Reasons for use

 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


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/

 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.

 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?

 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.