java unit testing - introduction
DESCRIPTION
Java Unit Testing - part 1TRANSCRIPT
![Page 1: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/1.jpg)
Java Unit Testing
Introduzione
Ing. Fabrizio GianneschiJava User Group Sardegna Onlus
![Page 2: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/2.jpg)
Riferimenti
● http://jroller.com/bitog
Java User Group Sardegna
● http://www.jugsardegna.org
Java.net Java User Groups Community
● http://community.java.net/jugs
![Page 3: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/3.jpg)
Introduzione
![Page 4: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/4.jpg)
Il ciclo di sviluppo
Sin dagli albori dell'informatica, gli ingegneri del software hanno tentato di schematizzare il cosiddetto “ciclo di sviluppo”
Per CdS si intende comunemente l'insieme di passi che, partendo dalla raccolta dei requisiti iniziali, porta al rilascio in produzione del software che (si spera) soddisfi tali requisiti
Per ridurre la complessità del CdS, lo si è sempre suddiviso in moduli (fasi), ciascuno a sua volta ingegnerizzabile e dalle prestazioni misurabili
![Page 5: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/5.jpg)
CdS e metodologie
● Negli anni, diverse “metodologie” di sviluppo del software hanno dato la propria definizione (e implementazione) di ciclo di sviluppo, nei modi più svariati
● Sono variate le notazioni, i linguaggi, le definizioni, il numero e la tipologia delle fasi
● Come sempre, “one size doesn't fit all”
![Page 6: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/6.jpg)
Waterfall
© Wikimedia commons, some rights reserved
![Page 7: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/7.jpg)
Iterativo incrementale
![Page 8: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/8.jpg)
Metodologie Agili
● Nate sul finire degli anni '90, boom intorno al 2002
● Di stampo iterativo-incrementale, puntano molto sulla valorizzazione del programmatore
● L'Agilità consiste nel ridurre non la qualità del lavoro, ma la complessità del processo, del codice
● Non è un “circo Barnum”, ma un badare al sodo!
![Page 9: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/9.jpg)
Costi del CdS
![Page 10: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/10.jpg)
“Agile keywords”
● Forte automazione
● Documentazione ridotta al minimo
● Enfasi sugli standard
● Roleplay
● Integrazione frequente, se non continua
● Valori
● Test, test, test...
![Page 11: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/11.jpg)
Testing
● Il testing è la fase del CdS che serve a rilevare la presenza di errori
● Ne discende che:– Non serve a correggerli– Non garantisce che non ce ne siano
● Perciò, è importante testare il maggior numero di funzioni, il più spesso possibile
● È efficace se fa sì che si rilevino anomalie
● Può essere manuale, automatico, misto
![Page 12: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/12.jpg)
Debugging & Logging
● Complementari del testing
● Aiutano a trovare gli errori e a correggerli
● Debug– Non automatizzabile, per definizione– Richiede che il codice sia in esecuzione– Richiede in genere un IDE– Complicato su sistemi remoti e/o complessi
● Log– Utile e sempre raccomandato
● Purchè non si riduca a delle System.out.println()....
![Page 13: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/13.jpg)
Test manuali
● Un tester (umano) riproduce i casi d'uso dell'applicazione e compila un rapporto
● Molti svantaggi:– Limitati quasi sempre al front end– Lentezza– Error-prone– Soggettività
● Unico vantaggio– Intelligenza
![Page 14: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/14.jpg)
Esempio di soggettività
Test: verificare che la componente di colore rosso sia >127
R = 255R = 0 ?
R = 150
![Page 15: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/15.jpg)
Test Automatici● Suite di test eseguiti automaticamente da un software
(es: JUnit)
● Eliminano la necessità dell'intervento umano
● Possono scatenare eventi (mail, build, deploy...)
● Possono generare log, statistiche, documentazione
● Rapidi
● Ripetibili
● Parametrizzabili
● Ottimizzabili
![Page 16: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/16.jpg)
Test Driven Development
● Metodologia Agile incardinata sui test automatici
● In due parole, il motto è: “scrivere i test prima del codice”
● Suona come eretica per i neofiti e per i non avvezzi alle metodologie molto codice-centriche e dinamiche
● In realtà, ha le sue profonde motivazioni
![Page 17: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/17.jpg)
Motivazioni del TDD
Assunto di base:“È virtualmente impossibile scrivere un sw non banale senza
commettere errori, né garantire al 100% che il software di terze parti lo sia”
➔ Un software senza test non è affidabile.(Guidereste mai un'automobile non testata?”)
➔ Il testing è necessario
![Page 18: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/18.jpg)
● Testare, comunque, costa.➔ Prima si trova un difetto, e meglio è➔ Se testo in anticipo, ed impedisco di rilasciare codice non
testato, sono sicuro che il codice in produzione soddisfa tutti i test
● Testare prima, implica ragionare meglio sul design e a chiarire cosa deve fare un pezzo di codice
● L'implementazione non è (immediatamente) rilevante, purché il test funzioni
![Page 19: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/19.jpg)
“Old style” testing
Creo i test
Eseguo i test
Test ok?
Rilascio il codice
Correggo il codice
Scrivo il codice
![Page 20: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/20.jpg)
Ciclo del TDD
http://www.nilkanth.com
![Page 21: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/21.jpg)
Schematizzando...
1) Scrivere un test per verificare una funzionalità
2) Eseguire tutti i test(L'ultimo scritto non dovrebbe passare, la prima volta)
3) Scrivere del codice per far passare i test
4) Rieseguire i test finchè non passano
5) Fare del refactoring
6) Ripetere tutto finchè ci sono test da aggiungere
![Page 22: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/22.jpg)
Bugfixing
● Quanto appena detto vale anche per il bugfixing!
● Si rileva un bug– Si scrive il test che riproduce il contesto del bug– L'obiettivo del test è assicurare che il funzionamento sia
quello corretto– Si scrive il codice che passa il test (ergo: si risolve
implicitamente il bug)
● Risultato?– Quella situazione d'errore è d'ora in poi “presidiata” da un
test
![Page 23: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/23.jpg)
Benefici del TDD
● Tempestiva risoluzione dei problemi
● Garanzia di funzionamento, ora e domani
● Mai più paura di “rompere tutto” aggiungendo qualcosa...
● ...perchè aggiungere è più facile
● Si tende a lavorare per interfacce, non per implementazioni
● Meno test manuali
● Robustezza, Manutenibilità
![Page 24: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/24.jpg)
Regole d'oro del TDD
![Page 25: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/25.jpg)
Test first, always
● Processo “red/green”– Fail, Pass, Refactor
● Se non si testa subito, lo si dovrà fare dopo.– Più difficile– O, peggio, non lo si farà
● 100% di successo– Altrimenti, non si integra né si rilascia
![Page 26: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/26.jpg)
Separation of concerns
● MAI mischiare il codice di test con quello “di produzione”
public MyClass{ ... public void myMethod(...){ //some code here ... if (isDebugMode() == true){ ... }else{ ... } }}
![Page 27: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/27.jpg)
public MyClass{ ... public void myMethod(...){ //some code here ... ... }}
public MyClassTest{ ... public void testMyMethod(){ ... //test goes here!!!! ... }}
![Page 28: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/28.jpg)
“Houston, we've a problem...”
● Se non riesci a scrivere il test...– vuol dire che il design è fatto male
● Se non riesci a far passare un test...– vuol dire che il codice è scritto male, oppure il design è
troppo complesso
● Se non hai voglia di eseguire i test “perché ci mettono troppo”... – rivedi l'automazione (build, setup, integrazione...)
![Page 29: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/29.jpg)
Bad smells....
● Se i test sembrano tutti uguali, o li fai col “cut&paste”, non stai testando bene
● Se hai troppe dipendenze in un test, si romperà più facilmente
● Se un test va sempre bene anche quando non dovrebbe
![Page 30: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/30.jpg)
Tipologie di test
![Page 31: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/31.jpg)
Tipologie di test
● Test unitari
● Test d'integrazione
● Test funzionali (o d'accettazione)
● Test regressivi
● Test di carico (stress test)
![Page 32: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/32.jpg)
Test unitari
● Testano unità elementari di codice
● Principio fondamentale: isolamento
● Come definire l'unità?– In genere, in Java, è una classe– Ogni classe, una classe di test– Ogni metodo, uno o più metodi di test
● Di responsabilità dello sviluppatore
● Tool: JUnit
![Page 33: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/33.jpg)
Test d'integrazione
● Test che verificano il funzionamento di più unità che collaborano tra loro– Non è detto che due unità perfette collaborino
perfettamente
● In genere, sono eseguiti successivamente al commit nel CVS– L'XP prevede una macchina d'integrazione
● La responsabilità può essere del programmatore o di un team
● Tool: CruiseControl
![Page 34: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/34.jpg)
Test funzionali
● Verificano la corretta esecuzione di complete funzionalità verticali, sino al back end (“carotaggio”)
● Se coincidono con quanto vuole il cliente, o sono da egli scritti, sono anche d'accettazione
● Comportano il test del front-end (in genere il più costoso)
● Tool: HttpUnit, Canoo, Selenium
![Page 35: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/35.jpg)
Test di regressione
● Servono a verificare che il codice funzionante sino a ieri funzioni anche oggi– Spesso, il codice che funzionava per qualche motivo non
funziona più– Quasi sempre, perchè il codice era fragile
● In pratica, si rieseguono tutti i vecchi test, si scova l'errore e si corregge
● Impliciti in molte metodologie agili (es: XP)
![Page 36: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/36.jpg)
Test di carico e stress
● Portano il sistema alle condizioni limite in fatto di volume di dati gestiti, accessi e traffico
● Tool: JMeter
![Page 37: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/37.jpg)
Stub e Mock
![Page 38: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/38.jpg)
Test sotto dipendenze
● L'isolamento è la condizione ideale per eseguire i test
● Purtroppo, spesso non è possibile testare tutti i componenti in tali condizioni per via delle dipendenze– Altri componenti– Risorse dell'Application Server (connection pool, mail,
librerie...)
![Page 39: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/39.jpg)
Esempio: servlet
final String WELCOME = “Benvenuto tra noi”;public void doGet(HttpServletRequest req, HttpServletResponse res){
HttpSession session = req.getSession(); Person p = session.getAttribute(“user”); if ( p == null ){ ..//not authenticated }else{ ... ... } }
Come simulare la request?
Come far sì che la sessione sia nello
stato voluto?
![Page 40: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/40.jpg)
Esempio: mail
● Supponiamo di dover effettuare dei test sul database di preproduzione (dati reali)
● Devo testare se la procedura di rinnovo password spedisce la mail al destinatario
● Come eseguire i test senza inondare i veri clienti di email?
![Page 41: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/41.jpg)
Soluzione: Stub e Mock
● Sono oggetti che simulano il comportamento di altri– Più semplici– Realizzati e controllabili dal programmatore
● La differenza tra stub e mock è molto sottile
● Stub: forniscono risposte “preconfezionate”, possono registrare informazioni sullo stato– In genere si aggiungono metodi rispetto all'interfaccia
reale
● Mock: verificano il comportamento, più a grana fine
![Page 42: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/42.jpg)
Esempio: Stub
public interface MailService {
public void sendMessage (Message msg);
}
public class MailServiceStub implements MailService {
private List<Message> messages = new ArrayList<Message>();
public void sendMessage (Message msg) {
messages.add(msg);
}
public int getNumberSent() {
return messages.size();
}
}
![Page 43: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/43.jpg)
Stub Test
class SMTPServerTest public void testSend() { MailService srvc = new MailServiceStub(); SMTPServer smtp = new SMTPServer();
smtp.setService(srvc);
List<Messages> msg = DummyMessages.create(1);smtp.send(msg);if (srvc.getNumberSent == 1){ ...//test ok}
}
Classe “dummy”
![Page 44: Java Unit Testing - Introduction](https://reader037.vdocument.in/reader037/viewer/2022100304/5484c4405806b5cc588b467d/html5/thumbnails/44.jpg)
Licenza Creative Commons (sunto)
Attribuzione-Non commerciale-Condividi allo stesso modo
3.0 Unported
Tu sei libero di modificare, riprodurre, distribuire, comunicare al pubblico, esporre inpubblico, rappresentare, eseguire e recitare quest'opera.
Alle seguenti condizioni:
● Attribuzione. Devi attribuire la paternità dell'opera nei modi indicati dall'autore o da chi ti ha dato l'opera in licenza e in modo tale da non suggerire che essi avallino te o il modo in cui tu usi l'opera.
● Non commerciale. Non puoi usare quest'opera per fini commerciali.
● Condividi allo stesso modo. Se alteri o trasformi quest'opera, o se la usi per crearne un'altra, puoi distribuire l'opera risultante solo con una licenza identica o equivalente a questa.
● Testo completo della licenza completa su:http://creativecommons.org/licenses/by-nc-sa/3.0/legalcode