Collaudare i metodi

[Bombonera]

Salve a tutti,

la domanda è un po stupida. Allora vorrei sapere quando mi chiedono di collaudare un metodo lo posso fare con JUnit ?

[andbin]

Allora vorrei sapere quando mi chiedono di collaudare un metodo lo posso fare con JUnit ?

Beh, sì ma hai chiari i concetti basilari alla base dello "unit testing"?
EDIT: e del testing in generale.

[Bombonera]

Beh, sì ma hai chiari i concetti basilari alla base dello "unit testing"?
EDIT: e del testing in generale.

No, dove posso trovare del materiale sul unit testing ?

oppure non lo so se mi puoi dare qualche dritta tu.....mi fai un grande favore.

[andbin]

No, dove posso trovare del materiale sul unit testing ?

oppure non lo so se mi puoi dare qualche dritta tu.....mi fai un grande favore.

Ok, sul testing purtroppo di concetti e metodologie ce ne sono parecchi. Non ho link pronti da fornirti al momento. Posso però darti una visione abbastanza generale, che tra l'altro mi permette di parlare di argomenti di cui ho ampliato la mia conoscenza proprio di recente grazie ad un ottimo libro.

Di tipi di test ne esistono diversi, tra cui principalmente gli "unit test" e gli "integration test". Questi ultimi vengono usati per testare la corretta "integrazione" tra più moduli. Cosa è un "modulo", dipende. La granularità può variare da una singola classe a un intero sistema.
In sostanza, detto un po' genericamente, si testano più "strati" di una applicazione/sistema.

Lo "unit test" invece è focalizzato sul test di una singola unità. Anche qui la granularità può variare ma al livello più tipico e basilare (e parlando di Java) si intende il test di una singola classe. La classe in questo caso è quello che viene chiamato SUT (System Under Test). La cosa importante è che lo unit testing deve testare il SUT in completo isolamento.

Il punto/problema è che sono poche le classi che possono compiere i loro lavori in totale isolamento senza bisogno di altre "entità". Invece è più probabile che il SUT abbia bisogno di una serie di altri oggetti chiamati "collaboratori" (o DOC, Depended On Component).

Siccome il test deve essere fatto in isolamento, questi collaboratori non devono essere quelli "reali", potrebbero infatti arrivare ad usare DB, file-system, configurazioni varie, ecc... Vuol dire che i DOC vanno sostituiti con quelli che vengono definiti test doubles, cioè varie tipologie di oggetti "fittizi" usati solo per facilitare il test del SUT in isolamento.

Detto in altro modo: se per fare un test devi preparare e/o rendere disponibile al SUT: un DB, un context, una configurazione, file vari, ecc... semplicemente NON stai facendo uno "unit test".

Ora c'è un'altra questione però: come vengono forniti i DOC al SUT? Se il design della classe SUT è buono, cioè i DOC possono essere assegnati dall'esterno "iniettandoli" tramite costruttori e/o metodi setter allora anche il testing sarà facilitato, perché è facile iniettare oggetti fittizi in modo che il SUT sia testato in isolamento.
Se invece il design non è particolarmente buono, il SUT crea molti collaboratori con new Xyz() o tramite metodi statici factory o cose del genere, ci sono almeno due strade:

a) Se puoi farlo, puoi effettuare un redesign della classe in modo che non sia più strettamente accoppiata ai collaboratori. Possibilmente sfruttando anche astrazioni con le interface Java.

b) Se non puoi applicare un redesign, entro certi limiti è ancora possibile testare il SUT in isolamento ma JUnit non basta. Servono librerie di mocking apposite. Una è PowerMock. Anche se il SUT crea un collaboratore per conto suo con new CollabA(), PowerMock sfrutta truschini con classloader custom e manipolazioni a livello di bytecode per mockare costruttori, metodi statici e altre cose che normalmente è difficile/impossibile rendere "fittizi".

La soluzione a) sarebbe la preferibile, naturalmente. Con la b) devi andare ad esaminare e sapere esattamente cosa fa il SUT. Il punto è che se il SUT cambia nel suo codice interno (magari anche senza cambiare la funzionalità vista dall'esterno), il test o non ha più gran senso o si "spacca" proprio.

Non è molto lo so (ce ne sarebbe da dire 100 volte di più) ma spero ti sia utile.

[Bombonera]

ho letto tutto per 2 volte e devo dire che a quest'ora sono un po stanco . Ho capito qualcosa in generale, non tutto se devo essere onesto.

Sul collaudo ho trovato questo su internet e devo dire che è quello che cercavo:

http://www.apogeonline.com/2005/libr...laudo_2318.pdf

domani quando torno dal lavoro rileggo di nuovo tutto quello che hai scritto.

Come ho capito io quindi non si usa Junit.

domani posto qualche esercizio svolto per vedere se ho capito

Grazie mille

[andbin]

Come ho capito io quindi non si usa Junit.

I due framework di test principali sono: JUnit e TestNG. Uno di questi due lo DEVI usare. Poi a seconda delle necessità di "mocking" può essere necessario anche altro!

[Alex'87]

Come utility aggiungerei assertj, comoda per creare asserzioni in modo più naturale sopperendo a qualche mancanza di quelle integrate in junit.

http://joel-costigliola.github.io/assertj/

[Bombonera]

Come utility aggiungerei assertj, comoda per creare asserzioni in modo più naturale sopperendo a qualche mancanza di quelle integrate in junit.

http://joel-costigliola.github.io/assertj/

Molto buone.....thank you