In-container and database Testing

Ing. Fabrizio GianneschiJava User Group Sardegna Onlus

http://www.jugsardegna.org

Java Unit Testing

Test in-container

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

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

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

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

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

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

Workaround

import junit.framework.JUnit4TestAdapter;...public static junit.framework.Test suite() { return new Junit4TestAdapter(<classname>.class);}...

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

Classi del container

Classi del container

TestCase sul server Classi del container

Server JVM

Client JVM

TestCase sul client

Proxy redirector

●beginXxx()●endXxx()

●setUp()●testXxx()●tearDown()

cfg(es: web.xml)

HttpRequest

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

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

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>

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

Test di Servlet e JSP

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

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

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

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

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

Caso 1: test dell'HTML

● Banale, estende ServletTestCase

● Dal metodo testXXX si invoca il dispatching alla JSP

RequestDispatcher disp = config.getServletContext(). getRequestDispatcher("/pagina.jsp");disp.forward(request, response);

● Nel metodo endXXX si verifica l'output nella response

● Esistono però tool più specializzati

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()

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

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

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

“You need four databases”

● Un'organizzazione con quattro livelli di db consente un testing efficace

DEV

DEV

DEV

Integrazione Pre-produzione Produzione

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

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

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

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

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

Importante

● NON concentrarsi a testare il framework di persistenza– Hibernate, iBatis....

● Il test è della propria applicazione, non di quelle degli altri

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

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