Java Unit Testing - JUnit (2)

  • Published on
    26-Jun-2015

  • View
    4.420

  • Download
    2

DESCRIPTION

Java Unit Testing - part 3

Transcript

1. Java Unit Testing JUnit (2)Ing. Fabrizio Gianneschi Java User Group Sardegna Onlus http://www.jugsardegna.org 2. JUnit (2) http://www.junit.org 3. Fixture Scrivere i test divertente, ma pu diventare anche ripetitivo La ripetitivit crea brutto codice, difficile da mantenere Una delle maggiori fonti di duplicazione del codice sono le inizializzazioni degli oggetti JUnit mette a disposizione il meccanismo delle fixture Una fixture un insieme di dati o risorse comuni, necessarie in pi test 4. setUp e tearDown Sono metodi di TestCase e vengono chiamati rispettivamente prima e dopo ogni testXXX() Luogo ideale per creare oggetti, aprire e chiudere connessioni al database, eccetera Riducono le LOC dei test Il codice delle fixture condiviso quindi tra tutti i test del TestCase Se alcuni non ne necessitano, forse meglio mettere il relativo codice comune in dei semplici utility method 5. Esempioprivate Connection myConn;protected void setUp() throws Exception{MyConn = DatabaseStub.createConnection();}...public void testXyz(){Statement st = myConn.createStatement();...}protected void tearDown() throws Exception{myConn.close();} 6. Eseguire la fixture una volta sola In alcuni casi, pu essere utile eseguire la fixture una volta sola per tutta la suite Anzich ricorrere a degli ineleganti flag, si usa il pattern Decorator (o Wrapper), tramite la classe TestSetup 7. TestSetup public class DbTest extends TestCase{ public static Test suite(){ TestSuite suite = new TestSuite(DbTest.class); TestSetup wrap = new TestSetup(suite){ public void setUp() throws Exception{ } public void tearDown() throws Exception{ } }; return wrap; } public void testXXX(){ ...} } 8. Esercizi 9. Differenze tra Junit 3.8.x e 4.x 10. Cambio package Le classi principali stanno ora in org.junit.* anzich in junit.framework.*JUnit 3.8.1: package com.mycompany; import junit.framework.*; ... 11. Cambio package Le classi principali stanno ora in org.junit.* anzich in junit.framework.* JUnit 4.x: package com.mycompany; import org.junit.*; ... 12. Meno dipendenze Le classi di Test sono ora POJO e non ereditano pi da TestCase Una classe di test se c' almeno un metodo annotato come @Test JUnit 3.8.1: import junit.framework.TestCase; public class CalculatorTest extends TestCase{ ... } 13. Meno dipendenze Le classi di Test sono ora POJO e non ereditano pi da TestCase Una classe di test se c' almeno un metodo annotato come @Test JUnit 4.x: public class CalculatorTest { ... @Test public void .... } 14. Pi espressivit I metodi di test non devono pi obbligatoriamente avere la forma testXXX() Viene eseguito dal framework ogni metodo annotato come @Test JUnit 3.8.1: ... public void testMetodoUno(){...} public void nonMiEsegue(){...} public void testMetodoDue(){...} ... 15. Pi espressivit I metodi di test non devono pi obbligatoriamente avere la forma testXXX() Viene eseguito dal framework ogni metodo annotato come @Test Devono comunque restare void e senza parametri JUnit 4.x: @Test public void miEsegue(){...} @Test public void esegueAncheMe(){...}public void nonMiEsegue(){...} ... 16. Ancora pi espressivit Anche i metodi setUp() e tearDown() sono sostituibili con metodi annotati public void setUp()--------> @Before public void tearDown() --------> @After Esempio: @Before public void initResources(){...} 17. Problema Se le classi di test non ereditano pi da TestCase, come invocare le asserzioni? Soluzione: Grazie agli import statici di Java 5, rimane tutto come prima!import static org.junit.Assert.*; ... @Test public void myTestMethod(){ ... assertEquals(obj1,obj2); In realt, sta chiamando }Assert.assertEquals ! 18. Sempre sulle asserzioni... pi semplice verificare la presenza di eccezioni JUnit 3.8.1: try{ metodoCheSollevaUnaException(); fail(); }catch (Exception ex){ assertTrue(True) } JUnit 4.x: @Test(expected: Exception.class) public void verificaEccezione(){ ...} 19. No suite JUnit 4.x non fa uso delle suite come la precedente versioneimport org.junit.runner.RunWith; import org.junit.runners.Suite; import org.junit.runners.Suite.SuiteClasses; @RunWith(Suite.class) @SuiteClasses({TestUno.class, TestDue.class, TestTre.class}) public class JUnit4Suite { } 20. Timer possibile ora controllare se un test impiega troppo tempo oppure va in timeout 1000 = 1 s @Test (timeout = 100) public void provaConnessione(){ ... url.openConnection(); ... } 21. Ignorare i test In JUnit 3.8.1, tutti i metodi che non iniziano per test vengono ignorati dal framework JUnit 4.x consente di annotarli come @Ignore I TestRunner tengono conto dei test ignorati, per non perderli in mezzo al codice @Ignore @Test public void metodoIgnorato(){ ... } 22. Altre novit Aggiunti metodi assert per testare i vettori assertEquals(Object[], Object[]) Due annotazioni comode per le fixture uniche per classe @BeforeClass e @AfterClass (devono essere statici) Nuovo TestRunner, eliminata swingui 23. Test Parametrici JUnit 4.x dispone di una soluzione elegante al problema dei test da eseguire con un numero molto esteso di combinazioni di parametri in ingresso Si utilizzano cos: si crea il metodo @Test parametrico si creano tante variabili d'istanza quanti sono i nomi sono quelli dei parametri di @Test si crea un costruttore del test che ha per parametri la n- upla identica alle variabili d'istanza si crea un metodo statico @Parameters che deve restituire una Collection (contiene le n-uple di parametri con i valori) si annota la classe con @RunWith(Parameterized.class) 24. Esempio (1/2) @RunWith(Parameterized.class) public class ParameterTest{private int par1;private String par2;public ParameterTest(int p1, String p2){par1 = p1;par2 = p2;} 25. Esempio (2/2) @Parameters public static Collection creaParametri(){ ...return Arrays.asList(new Object[][] { {1, pippo }, {100, paperino}, {1000, pluto}}}); } @Test public void testParametrico(){ ...//qui uso par1 e par2 } } 26. Ant e JUnit 4.x Alcuni problemi con Ant

Recommended

View more >