JUnit

1. JUnit Studio dell’ambiente e realizzazione di un caso di studio Annalisa Torella

2. testing: vantaggi e svantaggi unit testing JUnit: generalità caso di studio in JUnit

3. Le leggi della programmazione Legge di Murphy “All programs have errors” Corollario di Sod “The errors will manifest at the least convenient moment” Commento di O'Toole “Murphy was an optimist” Legge di Jenkinson “It won't work” Legge di Brooke “Adding manpower to a late software makes it later”

4. La soluzione: testing • “Il sofware testing è il processo di verifica dinamica del comportamento di un programma su un insieme finito di test case scelti adeguatamente nel dominio di input, rispetto al comportamento atteso specificato” [A. Bertolino] • nessuna dimostrazione che non esistono errori nel programma • attività onerosa • tempo, risorse • maggiori benefici se automatizzato

5. Problemi relativi al testing • fatto troppo tardi • impossibilità di riuso dei test case • test case v1.0 ≠ test case v5.2 • incompleto • non tutte le parti del programma possono essere testate

6. Vantaggi del testing • meno bug • meno produzione (NOIOSA) di patch, più sviluppo (INTERESSANTE) • prodotti migliori e più robusti • più clienti per l’azienda • più orgogliosi dell’azienda e dei suoi prodotti • “Vedi caro, cosa ho costruito!” • release più veloci delle nuove versioni • sonni più tranquilli

7. Svantaggi del testing • none! • absolutely none! • absolutely, definitively none! • absolutely, definitively, surely none! • absolutely, definitively, surely, conclusively none! • absolutely, definitively, surely, conclusively, decisively none! • absolutely, definitively, surely, conclusively, decisively, positively none!

8. Unit test • unit • prima dell’era OO • naturale astrazione in OO di classe o oggetto • unit test  test di unità “atomiche” • metodo, pezzo di codice, componente, sistema

9. JUnit • framework per scrivere test • ideato da Erich Gamma e Kent Beck • unit test test di un metodo • standard de facto per unit test in Java • sfrutta le capacità di riflessione di Java • valido aiuto per il programmatore • testing automatizzato • definisce ed esegue test e test suite • non incluso nella SDK di Sun, ma integrato in molti IDE • BlueJ, JBuilder, Eclipse

10. JUnit

11. Comandi di JUnit • assertTrue(boolean condition)assertFalse(boolean condition) • assertSame(Object expected, Object actual)assertNotSame(Object expected, Object actual) • == per il confronto • assertEquals(Object expected, Object actual) • metodo .equals() per il confronto • overloaded per tutti i tipi di primitive • metodi “speciali” per float e double con un parametro delta • assertNull(Object o)assertNotNull(Object o) • fail() metodi overloaded : stringa come primo argomento

12. Un semplice esempio import junit.framework.*; public class SimpleTest extends TestCase { public SimpleTest(String name) { super(name); } public void testSimpleTest() { int answer = 2; assertEquals((1+1), answer); } } • sottodirectory dei comandi • estensione di TestCase e collezione di unit test • costruttore (obbligatorio fino alla versione 3.7) • nuove istanze del test case • String name  nome unit test • unit test • metodo pubblico e senza argomenti

13. Caso di studio: il gioco di Hex

14. Caso di studio: il gioco di Hex

15. Caso di studio: il gioco di Hex

16. Caso di studio: il gioco di Hex

17. Caso di studio: il gioco di Hex

18. Caso di studio: il gioco di Hex

19. Caso di studio: il gioco di Hex

20. Caso di studio: il gioco di Hex

21. Caso di studio: il gioco di Hex • dal punto di vista del giocatore Nero • obiettivo • stabilire se una data configurazione della scacchiera è vincente per il giocatore • valutazione basata sulle connessioni virtuali • il Bianco non può impedire al Nero di connettere x e y • regole di deduzione per comporre connessioni virtuali

22. Caso di studio: implementazione Programma principale • definizione della dimensione della scacchiera • inizializzazione della scacchiera con i pezzi • inizializzazione del grafo delle celle • unione delle celle nere adiacenti in blocchi unici • calcolo delle connessioni virtuali di livello zero • applicazione delle regole di deduzione, fino a quando è possibile

23. Caso di studio: testing con JUnit • due classi • Graph.java • Hexy.java • due approcci al testing diversi • GraphTest.java: metodi assertXXX() e parametrizzazione • HexyTest.java: proprietà valide e simulazione esecuzione

24. Caso di studio: GraphTest.java • caratteristiche • istanza da file xml • generazione casuale del numero di parametri e dei parametri stessi • unit test nella suite variano in base ai parametri disponibili • metodi di setUp() e tearDown() che creano e distruggono l’istanza per ogni unit test • forma rudimentale di stress testing, combinando istanze di TestSuite e ReapetedTest • output su file di log • problemi incontrati • uso dei thread per lo stress testing

25. Caso di studio: GraphTest.java begin lettura unica dell’istanza; generazione casuale dei parametri; selezione automatica degli unit test eseguibili; while( test eseguibile){ per ogni volta che il test deve essere eseguito{ creazione di una copia dell’istanza; esecuzione dello unit test; distruzione della copia dell’istanza; } } scrittura su file di output dei risultati del test; end.

26. Caso di studio: GraphTest.java public void testDelEdge() { ... if (graph.isEdge(firstNode, secondNode)) { graph.delEdge(vi, vj); assertTrue(graph.getWeightEdge(firstNode, secondNode) == INF); assertTrue(graph.getWeightEdge(secondNode, firstNode) == INF); } else { fail(" Impossibile eliminare un arco non esistente. "); } } ?

27. Caso di studio: GraphTest.java public void testDelEdge() { ... if (graph.isEdge(firstNode, secondNode)) { graph.delEdge(vi, vj); assertTrue(graph.getWeightEdge(firstNode, secondNode) == INF); assertTrue(graph.getWeightEdge(secondNode, firstNode) == INF); } else { fail(" Impossibile eliminare un arco non esistente. "); } } public void delEdge(Vector v1, Vector v2) { ... if (isEdge(nI, nJ)){ edges[nI][nJ] = -1.0; edges[nJ][nI] = -1.0; } } edges[nI][nJ] = INF; edges[nJ][nI] = INF;

28. Caso di studio: HexyTest.java • caratteristiche • istanza unica per tutti gli unit test • metodi setUp() e tearDown() speciali • molto importante ordine di esecuzione dei test • definizione di proprietà valide per garantire l’indipendenza dei test dall’istanza • problemi incontrati • sequenziamento dei metodi per simulare una completa esecuzione del programma

29. Caso di studio: HexyTest.java begin creazione dell’istanza; sia  l’ordinamento esatto degli unit test per simulare un’esecuzione del programma per ogni unit test in { esecuzione dello unit test; } distruzione dell’istanza; end.

30. Caso di studio: HexyTest.java public void testApplyAndOrRules() { if (!hexy.isWin()) { hexy.applyAndOrRules(); } Vector v = hexy.getVirtConn(); if (hexy.isWin() && v.size() > 0) { assertTrue(hexy.isVirtualConn(v, SORGENTE, destinazione)); } else { ... } } ?

31. Caso di studio: HexyTest.java public void testApplyAndOrRules() { if (!hexy.isWin()) { hexy.applyAndOrRules(); } Vector v = hexy.getVirtConn(); if (hexy.isWin() && v.size() > 0) { assertTrue(hexy.isVirtualConn(v, SORGENTE, destinazione)); } else { ... } } PROBLEMA • nessun controllo sulla situazione iniziale SOLUZIONE • inserito controllo  modifica dei metodi

32. Caso di studio: approccio al testing • regole di “buona programmazione” • unico assertXXX() in ogni unit test • metodi assertXXX() con messaggio • messaggio su cosa dovrebbe essere vero, non su cosa è andato storto • combinazione delle potenzialità di JUnit • parametrizzazione del test • generazione casuale parametri + proprietà valide • copertura del codice • almeno un test per ogni metodo principale new

33. Caso di studio: limiti di JUnit • copertura del codice • tool aggiuntivi (Hansel e Coverlipse) • costo del testing • tipo di applicazione • struttura del codice • impossibilità di testare metodi richiamati all’interno di altri (HexyTest.java) • impossibilità di testare metodi privati