0
Java Unit Testing



In-container and database Testing


    Ing. Fabrizio Gianneschi
Java User Group Sardegna Onlus
  htt...
Test in-container
Quando usare i mock object?
●   I mock sono consigliati quando l'oggetto reale da
    rimpiazzare:
    –   ha un comportam...
Usare oggetti mock
●   Abbiamo già visto come usare semplici oggetti mock
●   Crearne di numerosi è però complicato
●   Pe...
In-Container testing
●   È il testing “a motore acceso”
●   Si testano componenti il cui ciclo di vita è gestito da un
   ...
Cactus
●   Cactus è un framework per il testing di componenti J2EE
●   Tipicamente, test unitari
●   Spesso usato con Jett...
Nota
●   Cactus è disponibile nella versione 1.7.2
    –   per container J2EE 1.2
    –   per container J2EE 1.3
●   Non è...
Purtroppo...
●   Non è ancora compatibile con JUnit 4.x, anche se c'è un
    piccolo workaround...


“I found out that it'...
Workaround
import junit.framework.JUnit4TestAdapter;
...
public static junit.framework.Test suite() {
    return new Junit...
Sul client
●   C'è la console
●   Vengono eseguiti i metodi di inizializzazione
    –   beginXXX e endXXX
●   Sono esposte...
●setUp()                                         Classi del container
   ●testXxx()    TestCase sul server             Cla...
Sul server
●   Vive il Proxy redirector
    –   ServletTestRedirector
    –   JSPTestRedirector
    –   FilterTestRedirect...
Sul client (configurazione)
●   Deve essere resa disponibile una proprietà di sistema
    cactus.contextURL per consentire...
Sul server (configurazione)
●   Va modificato il web.xml con opportune entry per i
    proxy utilizzati:
<servlet>
  <serv...
Sul server (attenzione)
●   I componenti di Cactus non andrebbero inclusi nella
    distribuzione in produzione
    –   ri...
Test di Servlet e JSP
Testare le servlet
●   Cactus mette a disposizione una serie di oggetti impliciti
●   Tali oggetti hanno interfacce confor...
Esercizio
●   Creare una servlet di controllo del flusso
●   La servlet controlla la presenza di un parametro page
    nel...
Esercizio
●   Modificare la servlet precedente in modo tale che
    effettui direttamente la redirezione
     –   non solo...
Esercizio
●   Testare che una servlet riceva correttamente i dati di un
    form multipart/data
●   Per la spedizione dei ...
Testare le JSP
●   A differenza delle Servlet, che dovrebbero contenere
    solamente logica, le JSP possono presentare an...
Caso 1: test dell'HTML
●   Banale, estende ServletTestCase
●   Dal metodo testXXX si invoca il dispatching alla JSP
Reques...
Caso 2: TagLib
●   Sono classi Java, che vivono in un contesto di pagina
●   Il testcase estende JspTestCase
●   Si utiliz...
Caso 3: test logico
●   Le JSP in genere utilizzano JavaBean creati dalle Servlet,
    che glieli passano attraverso la re...
Test e basi di dati
Problemi
●   Il test dei db, o con i db, è uno dei più complessi
●   Il db è un'entità esterna
    –   No codice Java. No ...
Considerazioni
●   Un buon db test deve essere autosufficiente
    –   non deve essere sensibile, nel bene o nel male, all...
“You need four databases”
●   Un'organizzazione con quattro livelli di db consente un
    testing efficace



        DEV
...
Level one: development
●   Ogni sviluppatore dovrebbe avere un db a sua
    disposizione
    –   Preferibilmente in locale...
Level two: integration
●   È il livello dove si eseguono i test d'integrazione e
    funzionali
●   I responsabili sono se...
Level three: pre-production
●   Qui si testa l'ultima versione integrata funzionate, con
    dati (o partizioni di db) rea...
Level four: production
●   Dati reali
●   Nessun testing qui!
Java Db Testing
●   Serve quindi qualcosa che semplifichi ed automatizzi il
    pià possibile:
    –   lo start start/stop...
Caso tipico: Business Logic o Data
Access Logic da testare
●   Approccio suggerito:
    –   Mantenere i dati di inizializz...
Importante
●   NON concentrarsi a testare il framework di persistenza
    –   Hibernate, iBatis....
●   Il test è della pr...
Esercizi
●   Testare una classe di business che scrive direttamente
    sul database
●   La classe ha un metodo che legge ...
Licenza Creative Commons (sunto)
 Attribuzione-Non commerciale-Condividi allo stesso modo
 3.0 Unported
 Tu sei libero di ...
Java Unit Testing - In container and database testing
Upcoming SlideShare
Loading in...5
×

Java Unit Testing - In container and database testing

3,282

Published on

Java Unit Testing - part 4

Published in: Technology
1 Comment
4 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,282
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
89
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide

Transcript of "Java Unit Testing - In container and database testing"

  1. 1. Java Unit Testing In-container and database Testing Ing. Fabrizio Gianneschi Java User Group Sardegna Onlus http://www.jugsardegna.org
  2. 2. Test in-container
  3. 3. Quando usare i mock object? ● I mock sono consigliati quando l'oggetto reale da rimpiazzare: – ha un comportamento non deterministico – è difficile da inizializzare – ha un comportamento difficile da riprodurre – è lento – ha un'interfaccia grafica – non esiste ● Oppure, quando il test necessita di invocare dei metodi che nell'oggetto reale non esistono
  4. 4. Usare oggetti mock ● Abbiamo già visto come usare semplici oggetti mock ● Crearne di numerosi è però complicato ● Per fortuna, esistono numerosi framework già pronti all'uso: – JMock – EasyMock – rMock ● In generale, i mock sono utili per effettuare test out- container... ma possono essere usati anche per i test in- container ● Il problema è sempre il solito: controllare le dipendenze
  5. 5. In-Container testing ● È il testing “a motore acceso” ● Si testano componenti il cui ciclo di vita è gestito da un soggetto terzo (il container) ● Ci sono casi, infatti, in cui non è possibile fare a meno del container (es: HttpSession...) ● Oppure, quando non abbiamo stub abbastanza buoni o ● Tool: Cactus
  6. 6. Cactus ● Cactus è un framework per il testing di componenti J2EE ● Tipicamente, test unitari ● Spesso usato con Jetty, servlet container leggero e veloce – parte in circa 1s (Tomcat e altri impiegano di più) ● Poggia su JUnit ed estende alcuni suoi metodi ● La filosofia è simile a JUnit (setup, esecuzione, teardown...) ma distribuita tra client e server
  7. 7. Nota ● Cactus è disponibile nella versione 1.7.2 – per container J2EE 1.2 – per container J2EE 1.3 ● Non è disponibile espressamente per J2EE 1.4, anche se si può usare quello per la versione per la 1.3 ● Testato con Tomcat 5.x ● NO JavaEE 5 --e non ci sono date, al riguardo :-( ● Alternative: JUnitEE, HttpUnit (incluso in Cactus), EJB3Unit...
  8. 8. Purtroppo... ● Non è ancora compatibile con JUnit 4.x, anche se c'è un piccolo workaround... “I found out that it's possible to run the JUnit 4.x (annotated) tests with Cactus 1.7.2 minimaly with functionality of JUnit 3.8 tests. It's need to use: JUnit4TestAdapter that automatically makes JUnit 3.8 compatible test from JUnit 4.x test. There is only problem with displaying names of the tests but it's easy to repair it in source class (JUnitVersionHelper) of Cactus.”
  9. 9. Workaround import junit.framework.JUnit4TestAdapter; ... public static junit.framework.Test suite() { return new Junit4TestAdapter(<classname>.class); } ...
  10. 10. Sul client ● C'è la console ● Vengono eseguiti i metodi di inizializzazione – beginXXX e endXXX ● Sono esposte interfacce che ricalcano request, response, sessione... ● Serializza la chiamata e la spedisce ad un ProxyRedirector sul server ● In risposta, vengono raccolti gli output
  11. 11. ●setUp() Classi del container ●testXxx() TestCase sul server Classi del container ●tearDown() Classi del container cfg (es: web.xml) Server JVM Proxy redirector Client JVM HttpRequest ●beginXxx() TestCase sul client ●endXxx()
  12. 12. Sul server ● Vive il Proxy redirector – ServletTestRedirector – JSPTestRedirector – FilterTestRedirector ● “Sente” la chiamata, deserializza le informazioni e le interpreta – capisce che TestCase invocare (testXxx() ) ● Lo inizializza con setUp() ● Lo finalizza con tearDown() ● Vivono gli oggetti del container
  13. 13. Sul client (configurazione) ● Deve essere resa disponibile una proprietà di sistema cactus.contextURL per consentire a Cactus di chiamare il container ● Tre modi: – via command line ( java ... -Dcactus.contextURL=http://myhost/mypath ) – via System.setProperty() nel codice di inizializzazione dei test – via file di configurazione (cactus.properties) messo nel classpath (equivale alle properties) ● Allo stesso modo, va specificato il nome della classe da usare come Proxy – cactus.servletRedirectorName = ServletTestRedirector
  14. 14. Sul server (configurazione) ● Va modificato il web.xml con opportune entry per i proxy utilizzati: <servlet> <servlet-name>ServletTestRedirector</servlet-name> <servlet-class> org.apache.cactus.server.ServletTestRedirector </servlet-class> </servlet> ... <servlet-mapping> <servlet-name>ServletTestRedirector</servlet-name> <url-pattern>/ServletTestRedirector</url-pattern> </servlet-mapping>
  15. 15. Sul server (attenzione) ● I componenti di Cactus non andrebbero inclusi nella distribuzione in produzione – rimarrebbero disponibili dall'esterno, con gravi problemi di sicurezza ● Ricordarsi di modificare il web.xml al momento del deploy! – Sugg.: Usare un web.xml parametrico, modificato da Ant quando serve – Nota: usare due web.xml differenti prima o poi porta al disallineamento ● http://jakarta.apache.org/cactus/faq.html#faq_webxml_test_prod
  16. 16. Test di Servlet e JSP
  17. 17. Testare le servlet ● Cactus mette a disposizione una serie di oggetti impliciti ● Tali oggetti hanno interfacce conformi alla Servlet API ma l'implementazione è wrappata da Cactus – request ● request.setURL(host, ctx, path) ● request.addCookie(name, value) ● request.setRemoteUser(...) / .setHost(...) ● request.setRemoteIPAddres(...) – config ● config.setInitParameter / .setServletName – config.getServletWrapper() ● Non wrappati, ma a disposizione – response – session
  18. 18. Esercizio ● Creare una servlet di controllo del flusso ● La servlet controlla la presenza di un parametro page nella request ● page rappresenta il nome di una pagina da caricare ● inserisce un attributo nella request – Se page inizia per “/private/”, il valore dell'attributo è il nome della JSP di autenticazione – Altrimenti, mette page ● Verificare il funzionamento con Cactus
  19. 19. Esercizio ● Modificare la servlet precedente in modo tale che effettui direttamente la redirezione – non solo controllo, ma anche dispatching... ● Testare con Cactus... si può? ● Sì, ma non direttamente: ● Posso testare l'output della servlet ● Posso verificare che il target della redirezione esista
  20. 20. Esercizio ● Testare che una servlet riceva correttamente i dati di un form multipart/data ● Per la spedizione dei dati dal TestCase: ● http://jakarta.apache.org/cactus/faq.html#faq_send_multipart ● Per la ricezione dei dati dalla servlet: – Si può utilizzare la libreria Commons FileUpload – http://www.javastaff.com/article.php? story=20060628011504263
  21. 21. Testare le JSP ● A differenza delle Servlet, che dovrebbero contenere solamente logica, le JSP possono presentare anche grafica ● Pertanto, si distinguono 3 casi: – test dell'HTML / XHTML generato a seguito della logica – test delle TagLib JSP – test della logica, ma in isolamento
  22. 22. Caso 1: test dell'HTML ● Banale, estende ServletTestCase ● Dal metodo testXXX si invoca il dispatching alla JSP RequestDispatcher disp = config.getServletContext(). getRequestDispatcher(quot;/pagina.jspquot;); disp.forward(request, response); ● Nel metodo endXXX si verifica l'output nella response ● Esistono però tool più specializzati
  23. 23. Caso 2: TagLib ● Sono classi Java, che vivono in un contesto di pagina ● Il testcase estende JspTestCase ● Si utilizzano gli oggetti impliciti per inizializzare il test ● Si crea un'istanza del tag e le si passa l'oggetto implic. pageContext ● Si chiamano i metodi del CdV del tag – doStartTag(), doAfterBody(), doEndTag()... ● Si verifica che restituiscano il valore corretto ● Si controlla l'output (HTML, ...) del tag nel metodo endXXX()
  24. 24. Caso 3: test logico ● Le JSP in genere utilizzano JavaBean creati dalle Servlet, che glieli passano attraverso la request. Perciò: ● Si estende JSPTestCase ● Nel testXXX(), si creano tutti i bean necessari e si mettono nella request. ● Si fa il forward alla JSP ● Nel endXXX(), si controlla l'output
  25. 25. Test e basi di dati
  26. 26. Problemi ● Il test dei db, o con i db, è uno dei più complessi ● Il db è un'entità esterna – No codice Java. No refactoring... – Altri tool, altre interfacce, altre policy ● Il db è lento ● Il db è spesso condiviso – i test rischiano di sovrapporsi ● Il db è distribuito – Quali e quanti db testare? ● Il db è persistente – lo stato del db influisce sui test
  27. 27. Considerazioni ● Un buon db test deve essere autosufficiente – non deve essere sensibile, nel bene o nel male, alle modifiche al db effettuate da un altro test ● Un buon test crea tutti i dati che gli servono – il db deve essere inizializzato ad uno stato noto prima di eseguire il test ● Serve quindi almeno un db completamente separato da quello di produzione ● Non è necessario che il test ripulisca il db quando ha terminato ● Non è necessario cancellare / creare tutto il db per ogni test
  28. 28. “You need four databases” ● Un'organizzazione con quattro livelli di db consente un testing efficace DEV Integrazione Pre-produzione Produzione DEV DEV
  29. 29. Level one: development ● Ogni sviluppatore dovrebbe avere un db a sua disposizione – Preferibilmente in locale ● Lo sviluppatore dovrebbe avere libertà totale su start/stop/manage della propria istanza ● I dati sono privi di utilità e significato pratico, se non per i test ● Il db può rimanere in uno stato inconsistente ● Per ragioni di efficienza, è preferibile utilizzare db lightweight – In-memory db (Hypersonic, Derby...)
  30. 30. Level two: integration ● È il livello dove si eseguono i test d'integrazione e funzionali ● I responsabili sono sempre gli sviluppatori ● I dati sono ancora poco significativi ● Lo stato precedente del db non è significativo ● Le differenze di schema o errori vengono subito al pettine e vanno armonizzate
  31. 31. Level three: pre-production ● Qui si testa l'ultima versione integrata funzionate, con dati (o partizioni di db) reali, provenienti dal db di produzione ● Prima dei test, il db va riallineato con la produzione ● La responsabilità di eseguire i test è del Q&A ● Non si fa integrazione. ● Test di carico e di accettazione
  32. 32. Level four: production ● Dati reali ● Nessun testing qui!
  33. 33. Java Db Testing ● Serve quindi qualcosa che semplifichi ed automatizzi il pià possibile: – lo start start/stop dell'istanza del db – le modifiche allo schema – l'immissione e la cancellazione dei valori d'inizializzazione – ripeta le operazioni precedenti per ogni test case ● Per aiutarci in questo, esiste DbUnit – basato su JUnit
  34. 34. Caso tipico: Business Logic o Data Access Logic da testare ● Approccio suggerito: – Mantenere i dati di inizializzazione su file (xml, plain text, excel, ...) o hard coded ● Database In-Memory ● Inizializzare il db con dbUnit ● Invocare la logica da testare nel corpo del test ● Verificare il risultato: – verifica di comportamento della logica (può essere fatta anche senza dbUnit, con un mock / stub!!) – verifica delle azioni compiute sul db ● sempre con dbUnit, o via codice con delle SELECT
  35. 35. Importante ● NON concentrarsi a testare il framework di persistenza – Hibernate, iBatis.... ● Il test è della propria applicazione, non di quelle degli altri
  36. 36. Esercizi ● Testare una classe di business che scrive direttamente sul database ● La classe ha un metodo che legge un campo di una tabella e ne aggiorna il valore in base ad un criterio da lei stabilito (es: se maggiorenne pone il flag a Y) ● Esercizio 2: – Introdurre l'uso di un Data Access Object (DAO) – Testare anche il DAO
  37. 37. 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 in pubblico, 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×