1 / 33

JUnit

JUnit. Studio dell’ambiente e realizzazione di un caso di studio. Annalisa Torella. testing : vantaggi e svantaggi unit testing JUnit: generalità caso di studio in JUnit. Le leggi della programmazione. Legge di Murphy “ All programs have errors ” Corollario di Sod

kato
Télécharger la présentation

JUnit

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related