Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Testing Test Driver Development Design Improvement alias Refactoring Continuous Integration  e altre pratiche Domenico Bri...
Agenda <ul><li>Test Driven Development </li></ul><ul><li>Test Unitari con JUnit </li></ul><ul><li>MockObject </li></ul><ul...
Domanda... <ul><li>Chi scrive dei test per il proprio codice? </li></ul><ul><li>Bene....perchè? </li></ul>
I problemi durante lo sviluppo... <ul><li>Tempo di realizzazione </li></ul><ul><li>Non sappiamo come funziona (ma funziona...
Come migliorare la situazione? <ul><li>Usare TDD (non è la soluzione di tutto!!) </li></ul><ul><ul><li>Non scrivere codice...
Altri vantaggi di TDD... <ul><li>Il tuo design migliora ed evolve continuamente  </li></ul><ul><ul><li>si pensa al cosa e ...
E ancora… <ul><li>Usi il debugger sono quando necessario... </li></ul><ul><li>...e nel punto giusto (se i test sono suffic...
Due concetti: Alta coesione e basso accoppiamento <ul><li>Importati indici per indicare la qualità del codice </li></ul><u...
Cos’è il  Refactoring  (Design Improvement) <ul><li>Rifattorizzare indica la procedura che porta a migliorare il codice in...
NON Regressione... <ul><li>Si rifattorizza spesso, e il pericolo di inserire bug è alto. </li></ul><ul><li>Le suite di tes...
Ma...quando testare? <ul><li>Quando pensiamo ai test, spesso ci chiediamo: </li></ul><ul><li>Sono sufficienti </li></ul><u...
Creare nuovi test:  quando … <ul><li>Si aggiunge una nuova feature </li></ul><ul><li>Si ha un bug (“regression test”) </li...
Come scriverli <ul><li>Prima di  iniziare , fate una lista di tutti i test che  dovrete   scrivere : </li></ul><ul><ul><ul...
Ottimizzare i test... <ul><li>Se far funzionare il test richiede troppo tempo, spezzarlo in più parti </li></ul><ul><li>Se...
Ne vale la pena? <ul><li>Il testing porta via metà del tempo dello sviluppo... </li></ul><ul><li>ma... </li></ul><ul><ul><...
Costo di un bug e “località” Fonte: http://www.dia.uniroma3.it/~merialdo/didattica/aa2005-2006/poo/trasparenze/POO-17-test...
Quindi... <ul><li>Se ben progettati e mantenuti, i test aiutano a confinare i bug nella “zona verde” , ovvero con forti ca...
Testing e fasi di sviluppo <ul><li>Il testing NON è una fase dello sviluppo; va previsto in tutte le fasi, con significato...
Tipi di test <ul><li>Tantissime categorie, sommariamente: </li></ul><ul><ul><li>Unit testing </li></ul></ul><ul><ul><ul><l...
JUnit, the java testing framework <ul><li>Scritto da  Erich Gamma and Kent Beck </li></ul><ul><li>Open Source </li></ul><u...
JUnit Framework http://junit.sourceforge.net
Creare test con JUnit < 4.0 <ul><li>Si deriva da TestCase  </li></ul><ul><li>Si possono sovrascrivere i metodi setUp() e t...
Creare test con JUnit 4.X <ul><li>Si importa junit.framework.Assert che fornisce tutti i metodi statici per gli assert </l...
I metodi assert / fail <ul><li>Servono a verificare determinate condizioni (assert) o a segnalare un esito negativo  (fail...
Unit Best Practices 1/4 <ul><li>Separare il codice di test da quello da testare con cartelle sorgenti diverse </li></ul><u...
Unit Best Practices 2/4 <ul><li>I test devono essere indipendenti dal tempo </li></ul><ul><li>Indipendenti dalle impostazi...
Unit Best Practices 3/4 <ul><li>Non assumere un ordine preciso per l’esecuzione dei test, ma se necessario creare una Test...
Unit Best Practices 4/4 <ul><li>Non caricare le risorse dal file system con percorsi hard-coded: </li></ul><ul><li>public ...
DEMO <ul><li>Test JUnit 3.8.1 </li></ul><ul><li>Test JUnit 4 </li></ul>
Ant & JUnit Best Practices <ul><li>Usare  <junit>  per richiamare l’esecuzione dei test </li></ul><ul><li>Usare  <fail>,  ...
Passaggio di parametri al tests <junit printsummary=&quot;no”… <sysproperty key=&quot;docs.dir” file=&quot;${test.dir}”/> ...
TestRunners con swing (SwingUI)
Avviare il test con ANT <ul><li><junit printsummary=&quot;on&quot; errorProperty=&quot;test.failed&quot; failureProperty=&...
Report del test <ul><li><junitreport todir=&quot;${build}&quot;> </li></ul><ul><li><fileset dir=&quot;${build}&quot;> </li...
Report del test
DEMO <ul><li>Test JUnit 3.8.1 con ANT </li></ul>
Tutto bello...ma... <ul><li>Come testate un test che coinvolge una risorsa esterna? </li></ul><ul><li>Come testare eventi?...
Mock Object <ul><li>E' un oggetto finto che si comporta come l'originale </li></ul><ul><li>È più veloce </li></ul><ul><li>...
EasyMock <ul><li>Libreria OpenSource per creare MockObject a runtime </li></ul><ul><li>Necessita di Java5 (solo per le ver...
Usare EasyMock <ul><li>Regioni reg = new Regioni(); </li></ul><ul><li>Animale a = EasyMock.createMock(Animale.class); </li...
DEMO <ul><li>Test Mock Object </li></ul><ul><li>Test LocalDbExplorer </li></ul>
Atri tool xUnit <ul><li>SUnit (Per SmallTalk, considerato il padre di tutti gli unit test framework) </li></ul><ul><li>Cpp...
Continuous integration <ul><li>“ I s a software development practice where members of a team integrate their work frequent...
C.I.: punti salienti <ul><li>Build ad ogni commit </li></ul><ul><li>Test automatici eseguiti ad ogni commit </li></ul><ul>...
Ciclo di build di C.I. VCS Build Artifacts Dir Mail/Sound/Light… 1. Bootstrap 2. Check for modifications 3. Get the revisi...
CruiseControl <ul><li>http://cruisecontrol.sourceforge.net/ </li></ul><ul><li>Interfaccia Web per monitorare il processo d...
Come funziona CruiseControl
DEMO <ul><li>Test LocalDbExplorer  </li></ul><ul><li>con ANT e CruiseControl </li></ul>
Conclusioni <ul><li>“ Any program feature without an automated test simply doesn’t exist.” from Extreme Programming Explai...
Di cosa abbiamo parlato...
Riferimenti 1/2 <ul><li>Le slides di Bruno Bossola (JugTorino) al webbit 03: http://www.jugtorino.it/vqwiki/jsp/Wiki?LeSli...
Riferimenti 2/2 <ul><li>Cos’è XP http://www.xprogramming.com/xpmag/whatisxp.htm </li></ul><ul><li>http://www.pairprogrammi...
 
Upcoming SlideShare
Loading in …5
×

Testing

1,042 views

Published on

Published in: Technology
  • Be the first to comment

Testing

  1. 1. Testing Test Driver Development Design Improvement alias Refactoring Continuous Integration e altre pratiche Domenico Briganti 14/06/2006
  2. 2. Agenda <ul><li>Test Driven Development </li></ul><ul><li>Test Unitari con JUnit </li></ul><ul><li>MockObject </li></ul><ul><li>Refactoring </li></ul><ul><li>Continuos Integration </li></ul><ul><li>Vari ed eventuali  </li></ul>
  3. 3. Domanda... <ul><li>Chi scrive dei test per il proprio codice? </li></ul><ul><li>Bene....perchè? </li></ul>
  4. 4. I problemi durante lo sviluppo... <ul><li>Tempo di realizzazione </li></ul><ul><li>Non sappiamo come funziona (ma funziona!) </li></ul><ul><li>Non si realizzano componenti riusabili </li></ul><ul><li>Modifichi qui....e li spacca molto più in là (accorgendotene dopo un mese e con un giorno di debugger) </li></ul><ul><li>Il codice regredisce e invecchia più velocemente </li></ul><ul><li>Il prodotto consegnato ha dei bug ( sempre ) </li></ul><ul><li>Ecc.ecc.ecc.ecc (tanti ecc.!!!!) </li></ul>
  5. 5. Come migliorare la situazione? <ul><li>Usare TDD (non è la soluzione di tutto!!) </li></ul><ul><ul><li>Non scrivere codice senza che esista un test AUTOMATICO che fallisce </li></ul></ul><ul><ul><li>Si mantiene una TODO list </li></ul></ul><ul><ul><li>Sei costretto a pensare prima di scrivere un test... </li></ul></ul><ul><ul><li>...e a chiedere, subito, quando non capisci una funzionalità </li></ul></ul><ul><ul><li>Rifattorizzare spesso </li></ul></ul>
  6. 6. Altri vantaggi di TDD... <ul><li>Il tuo design migliora ed evolve continuamente </li></ul><ul><ul><li>si pensa al cosa e non al come </li></ul></ul><ul><ul><li>ma solo nella direzione necessaria </li></ul></ul><ul><ul><li>non c'è nulla di superfluo </li></ul></ul><ul><li>Per testare tu devi: </li></ul><ul><ul><li>realizzare molti oggetti </li></ul></ul><ul><ul><li>che fanno poche cose </li></ul></ul>
  7. 7. E ancora… <ul><li>Usi il debugger sono quando necessario... </li></ul><ul><li>...e nel punto giusto (se i test sono sufficientemente piccoli) </li></ul><ul><li>Descrivi il codice nel modo più rapido e aggiornato possibile... </li></ul><ul><li>...indicando cosa vuoi ottenere </li></ul><ul><li>Meno commenti, meno documentazione! </li></ul><ul><li>Libertà di rifattorizzare senza provare rimorsi! </li></ul><ul><li>basso accoppiamento fra gli oggetti e alta coesione </li></ul>
  8. 8. Due concetti: Alta coesione e basso accoppiamento <ul><li>Importati indici per indicare la qualità del codice </li></ul><ul><li>Coesione: fa riferimento al numero e alla eterogeneità dei compiti di cui una singola unità è responsabile (classe o metodo); Se ciascuna unità è responsabile di un singolo compito, diciamo che tale unità ha una alta coesione </li></ul><ul><li>Accoppiamento: L’accoppiamento si riferisce ai legami tra unità separate di un programma; Se due classi dipendono strettamente per molti dettagli l’una dall’altra, diciamo che sono strettamente accoppiate </li></ul>
  9. 9. Cos’è il Refactoring (Design Improvement) <ul><li>Rifattorizzare indica la procedura che porta a migliorare il codice in termini di: </li></ul><ul><ul><li>Prestazioni </li></ul></ul><ul><ul><li>Memoria consumata </li></ul></ul><ul><ul><li>Stile e comprensione </li></ul></ul><ul><li>Senza di fatto modificare il comportamento visto dall'esterno. </li></ul><ul><li>Si fa perché col passare del tempo la manutenzione del codice e l’aggiunta di nuove funzionalità provocano la perdita di coesione e aumentano l’accoppiamento </li></ul><ul><li>Porta a eliminare le duplicazioni nel codice (segno di scarso design) </li></ul>
  10. 10. NON Regressione... <ul><li>Si rifattorizza spesso, e il pericolo di inserire bug è alto. </li></ul><ul><li>Le suite di test ti proteggono dalla regressione </li></ul><ul><li>I bug non riappaiono all'improvviso (wow!) </li></ul><ul><li>Il tuo sistema funziona con continuità </li></ul>
  11. 11. Ma...quando testare? <ul><li>Quando pensiamo ai test, spesso ci chiediamo: </li></ul><ul><li>Sono sufficienti </li></ul><ul><li>Quale logica o dato testare </li></ul>Risposte????
  12. 12. Creare nuovi test: quando … <ul><li>Si aggiunge una nuova feature </li></ul><ul><li>Si ha un bug (“regression test”) </li></ul><ul><li>Si deve capire come funziona qualcosa (“learging test”) </li></ul><ul><li>Per spiegare il funzionamento di qualcosa </li></ul><ul><li>Ma soprattutto: </li></ul><ul><li>I test devono essere scritti prima del codice da testare, non lo testerete mai dopo!! </li></ul>
  13. 13. Come scriverli <ul><li>Prima di iniziare , fate una lista di tutti i test che dovrete scrivere : </li></ul><ul><ul><ul><li>Consente di tenere traccia di cosa dobbiamo fare </li></ul></ul></ul><ul><ul><ul><li>Permette di concentrarci su una cosa alla volta </li></ul></ul></ul><ul><ul><ul><li>Possiamo tenere sotto controllo l'avanzamento </li></ul></ul></ul><ul><li>Scegliete i dati senza spararli a caso, il test fa da documentazione </li></ul><ul><li>Isolandoli e che garantiscano la località degli errori </li></ul><ul><li>Rendi chiara la relazione tra dati di ingresso e di uscita . </li></ul><ul><li>separati dal codice applicativo (es. crearli in package diversi) </li></ul>
  14. 14. Ottimizzare i test... <ul><li>Se far funzionare il test richiede troppo tempo, spezzarlo in più parti </li></ul><ul><li>Se i test usano una risorsa difficile da usare, crea un “Mock Object” </li></ul><ul><li>Scrivi prima il test! </li></ul><ul><li>Se lavori in team lascia sempre i test funzionanti altrimenti barre rosse! </li></ul><ul><li>Se un test fallisce, devi avere un problema: se due test falliscono devi avere due problemi... </li></ul><ul><li>I test devono essere indipendenti dall'ordine in cui si lanciano. </li></ul>
  15. 15. Ne vale la pena? <ul><li>Il testing porta via metà del tempo dello sviluppo... </li></ul><ul><li>ma... </li></ul><ul><ul><li>Il tempo totale di sviluppo diminuisce </li></ul></ul><ul><ul><li>Il tempo di debugging diminuisce drasticamente </li></ul></ul><ul><ul><ul><li>Quando scavi col debugger nel codice non sai se finirai tra 1 minuto o tra 2 giorni (perché poi ti arrendi!) </li></ul></ul></ul><ul><ul><ul><li>Il costo di debugging è ritenuto di gran lunga la componente principale nella formazione del costo dei moderni progetti di software </li></ul></ul></ul>
  16. 16. Costo di un bug e “località” Fonte: http://www.dia.uniroma3.it/~merialdo/didattica/aa2005-2006/poo/trasparenze/POO-17-testing-tecniche.ppt
  17. 17. Quindi... <ul><li>Se ben progettati e mantenuti, i test aiutano a confinare i bug nella “zona verde” , ovvero con forti caratteristiche di località: </li></ul><ul><ul><li>i bug hanno caratteristiche tali da manifestarsi immediatamente e palesemente </li></ul></ul><ul><ul><li>il difetto nel codice è ricercabile in un numero di linee non eccessivamente elevato e comunque ben identificabili </li></ul></ul><ul><li>Le esecuzioni che manifestano il bug non sono mai troppo lunghe e/o troppe complesse </li></ul><ul><ul><li>in particolare non devono esserlo dal momento in cui l’errore si verifica a quello in cui si manifesta </li></ul></ul>
  18. 18. Testing e fasi di sviluppo <ul><li>Il testing NON è una fase dello sviluppo; va previsto in tutte le fasi, con significato e modalità diverse </li></ul><ul><li>Ripetizione dei test precedenti quando si localizzano e rimuovono difetti </li></ul>Maintenance <ul><li>Controllo di coerenza progetto/implementazione </li></ul><ul><li>Esecuzione dei test sul prodotto </li></ul>Coding <ul><li>Controllo di coerenza progetto/requisiti </li></ul><ul><li>Valutazione dell’architettura di sistema </li></ul><ul><li>Test del design </li></ul><ul><li>Generazione di dati di test funzionali e strutturali </li></ul>Design <ul><li>Generazione dei dati di test </li></ul><ul><li>Determinazione della strategia di test </li></ul><ul><li>Test dei requisiti e delle specifiche </li></ul>Analysis Attività di test Fase
  19. 19. Tipi di test <ul><li>Tantissime categorie, sommariamente: </li></ul><ul><ul><li>Unit testing </li></ul></ul><ul><ul><ul><li>Testare un’unità di codice, tipicamente un metodo/classe </li></ul></ul></ul><ul><ul><li>Integration testing </li></ul></ul><ul><ul><ul><li>Testare un modulo (es. Un package) </li></ul></ul></ul><ul><ul><li>Application testing </li></ul></ul><ul><ul><ul><li>Testare il codice dal punto di viste dell’utente (black box) </li></ul></ul></ul>
  20. 20. JUnit, the java testing framework <ul><li>Scritto da Erich Gamma and Kent Beck </li></ul><ul><li>Open Source </li></ul><ul><li>Dalla versione 4.0 fa anche uso delle annotazioni di Java 1.5 </li></ul><ul><li>Supporta asserzioni, suite test e report result </li></ul><ul><li>Integrato in tantissimi IDE e tool di build (ANT, Maven, CruiseControl…quasi tutti) </li></ul>
  21. 21. JUnit Framework http://junit.sourceforge.net
  22. 22. Creare test con JUnit < 4.0 <ul><li>Si deriva da TestCase </li></ul><ul><li>Si possono sovrascrivere i metodi setUp() e tearDown() che vengono richiamati ad ogni esecuzione di test </li></ul><ul><li>Si può utilizzare il costruttore della classe per istanziare oggetti usati da più test (ed eventualmente sovrascrivere finalize) </li></ul><ul><li>Si definiscono uno o più test con testXXX() </li></ul>setUp() testXXX() tearDown()
  23. 23. Creare test con JUnit 4.X <ul><li>Si importa junit.framework.Assert che fornisce tutti i metodi statici per gli assert </li></ul><ul><li>Si annotano I metodi richiamati allo prima e dopo la classe/test con: </li></ul><ul><ul><li>@BeforeClass </li></ul></ul><ul><ul><li>@AfterClass </li></ul></ul><ul><ul><li>@Before </li></ul></ul><ul><ul><li>@After </li></ul></ul><ul><li>Si definiscono uno o più test annotati con @Test </li></ul>
  24. 24. I metodi assert / fail <ul><li>Servono a verificare determinate condizioni (assert) o a segnalare un esito negativo (fail) </li></ul><ul><li>Esistono di diversi tipi assert : </li></ul><ul><ul><li>assertNotNull </li></ul></ul><ul><ul><li>assertEquals </li></ul></ul><ul><ul><li>assertTrue, assertFalse </li></ul></ul><ul><ul><li>assertSame, assertNotSame </li></ul></ul><ul><ul><li>ecc. ecc. ecc. </li></ul></ul><ul><li>Ognuno degli assert/fail con svariati tipi di parametri di input (Stringe, numeri, oggetti...) </li></ul><ul><li>Il primo parametro è quello atteso, il secondo è quello ottenuto dal test dell’oggetto . </li></ul>
  25. 25. Unit Best Practices 1/4 <ul><li>Separare il codice di test da quello da testare con cartelle sorgenti diverse </li></ul><ul><li>Compilarli insieme, questo comporta la loro sincronizzazione durante lo sviluppo </li></ul><ul><li>Anche per i test sono disponibili le tecniche dei linguaggi OO (subclassing, helper, ecc.ecc.) </li></ul><ul><li>Se la classe sotto test si chiama XXX , allora gli si associa una classe di test chiamata XXXTest (o xxxTestCase) nello stesso package </li></ul>
  26. 26. Unit Best Practices 2/4 <ul><li>I test devono essere indipendenti dal tempo </li></ul><ul><li>Indipendenti dalle impostazioni di locazioni/nazionalità, es.: </li></ul><ul><ul><li>Date date = DateFormat.getInstance ().parse (&quot;dd/mm/yyyy&quot;); </li></ul></ul><ul><ul><li>Calendar cal = Calendar.getInstance (); </li></ul></ul><ul><ul><li>Cal.set (yyyy, mm-1, dd); </li></ul></ul><ul><ul><li>Date date = Calendar.getTime (); </li></ul></ul><ul><li>Descriverli attraverso javadoc </li></ul>
  27. 27. Unit Best Practices 3/4 <ul><li>Non assumere un ordine preciso per l’esecuzione dei test, ma se necessario creare una TestSuite inserendo nell’ordine i metodi di test: </li></ul><ul><li>public class TestSuiteConOrdine extends junit.framework.TestSuite { </li></ul><ul><li>public static junit.framework.Test suite() { </li></ul><ul><li>TestSuite suite = new TestSuite(); </li></ul><ul><li>suite.addTest(new RegioniTest(&quot;testConMock1.....&quot;)); </li></ul><ul><li>suite.addTest(new RegioniTest(&quot;testConMock2.....&quot;)); </li></ul><ul><li>return suite; </li></ul><ul><li>} </li></ul><ul><li>} </li></ul>
  28. 28. Unit Best Practices 4/4 <ul><li>Non caricare le risorse dal file system con percorsi hard-coded: </li></ul><ul><li>public void setUp () { </li></ul><ul><li>FileInputStream inp (&quot;C:TestDatadataSet1.dat&quot;); </li></ul><ul><li>... </li></ul><ul><li>public void setUp () { </li></ul><ul><li>FileInputStream inp (&quot;dataSet1.dat&quot;); </li></ul><ul><li>.. </li></ul><ul><li>public void setUp () { </li></ul><ul><li>InputStream inp = SourceResourceLoader.getResourceAsStream (this.getClass (), &quot;dataSet1.dat&quot;); </li></ul>
  29. 29. DEMO <ul><li>Test JUnit 3.8.1 </li></ul><ul><li>Test JUnit 4 </li></ul>
  30. 30. Ant & JUnit Best Practices <ul><li>Usare <junit> per richiamare l’esecuzione dei test </li></ul><ul><li>Usare <fail>, errorproperty e failureproperty per notificare un evento di errore/failure nei test </li></ul><ul><li>Evitare di utilizzare haltonfailute </li></ul><ul><li>Usare <junitreport> per visualizzare il risultato del test </li></ul><ul><li>Passaggio di parametri usando <sysproperty> </li></ul><ul><li>Usare <cvs command=&quot;up -d -P&quot;/> in concomitanza con Continuous Integration </li></ul>
  31. 31. Passaggio di parametri al tests <junit printsummary=&quot;no”… <sysproperty key=&quot;docs.dir” file=&quot;${test.dir}”/> <sysproperty key=&quot;index.dir” file=&quot;${test.dir}/index”/> … </junit> private String docsDir = System.getProperty(&quot;docs.dir&quot;); private String indexDir = System.getProperty(&quot;index.dir&quot;);
  32. 32. TestRunners con swing (SwingUI)
  33. 33. Avviare il test con ANT <ul><li><junit printsummary=&quot;on&quot; errorProperty=&quot;test.failed&quot; failureProperty=&quot;test.failed&quot; fork=&quot;off&quot;> </li></ul><ul><li><formatter type=&quot;xml&quot;/> <!-- altri possibili valori brief e plain --> </li></ul><ul><li><classpath> </li></ul><ul><li><pathelement path=&quot;${bin}&quot;/> </li></ul><ul><li><fileset dir=&quot;${lib}&quot;> </li></ul><ul><li><include name=&quot;*.jar&quot;/> </li></ul><ul><li></fileset> </li></ul><ul><li></classpath> </li></ul><ul><li><test name=&quot;org.dometec.test.TestSuite&quot; haltonfailure=&quot;no&quot; todir=&quot;${build}&quot;/> </li></ul><ul><li></junit> </li></ul>
  34. 34. Report del test <ul><li><junitreport todir=&quot;${build}&quot;> </li></ul><ul><li><fileset dir=&quot;${build}&quot;> </li></ul><ul><li><include name=&quot;TEST-*.xml&quot;/> </li></ul><ul><li></fileset> </li></ul><ul><li><report format=&quot;frames&quot; todir=&quot;${build}/Test-html&quot;/> </li></ul><ul><li></junitreport> </li></ul><ul><li><fail if=&quot;test.failed&quot;>Unit tests failed.</fail> </li></ul>
  35. 35. Report del test
  36. 36. DEMO <ul><li>Test JUnit 3.8.1 con ANT </li></ul>
  37. 37. Tutto bello...ma... <ul><li>Come testate un test che coinvolge una risorsa esterna? </li></ul><ul><li>Come testare eventi? </li></ul><ul><li>Come testare eccezioni? </li></ul><ul><li>Come verificare iterazioni complesse? </li></ul><ul><li>Come testare Servelt e EJB? </li></ul><ul><li>Come testare un plugin per Eclipse? </li></ul><ul><li>Come testare… </li></ul>
  38. 38. Mock Object <ul><li>E' un oggetto finto che si comporta come l'originale </li></ul><ul><li>È più veloce </li></ul><ul><li>Esistono vari tools che ne facilitano la creazione </li></ul><ul><li>Aiutano a disaccoppiare le logiche </li></ul>
  39. 39. EasyMock <ul><li>Libreria OpenSource per creare MockObject a runtime </li></ul><ul><li>Necessita di Java5 (solo per le versioni > 2) </li></ul><ul><li>Crea Mock a partire da Interfacce (c’è un’estensione che permette di utilizzare anche classi invece di interfacce) </li></ul><ul><li>Verifica opzionalmente l’ordine di chiamata dei metodi e il numero di volte che vengono chiamati (anche tra mock object diversi) </li></ul>
  40. 40. Usare EasyMock <ul><li>Regioni reg = new Regioni(); </li></ul><ul><li>Animale a = EasyMock.createMock(Animale.class); </li></ul><ul><li>EasyMock.expect(a.getLocazioneGeografica()).andReturn(&quot;Europa&quot;); </li></ul><ul><li>EasyMock.replay(a); </li></ul><ul><li>reg.addAnimale(a); </li></ul>
  41. 41. DEMO <ul><li>Test Mock Object </li></ul><ul><li>Test LocalDbExplorer </li></ul>
  42. 42. Atri tool xUnit <ul><li>SUnit (Per SmallTalk, considerato il padre di tutti gli unit test framework) </li></ul><ul><li>CppUnit </li></ul><ul><li>XMLUnit </li></ul><ul><li>DbUnit </li></ul><ul><li>NUnit </li></ul><ul><li>PyUnit </li></ul><ul><li>RubyUnit </li></ul><ul><li>... </li></ul>
  43. 43. Continuous integration <ul><li>“ I s a software development practice where members of a team integrate their work frequently, at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly .“ </li></ul><ul><li>Martin Flower </li></ul>
  44. 44. C.I.: punti salienti <ul><li>Build ad ogni commit </li></ul><ul><li>Test automatici eseguiti ad ogni commit </li></ul><ul><li>Build veloci e incrementali attraverso la verifica del log del CVS/SVN </li></ul><ul><li>Tutti possono vedere cosa accade nel processo di build </li></ul><ul><li>Minimizza la probabilità di errori nella fase di integrazione </li></ul>
  45. 45. Ciclo di build di C.I. VCS Build Artifacts Dir Mail/Sound/Light… 1. Bootstrap 2. Check for modifications 3. Get the revision log Cruise Control Your project’s Build file Ant, Maven, Make 2. Run Build 5. Publish Artifacts 6. Send to publisher 1. Get the latest source 3. Tag source (optional) Project Specific Adapter - Ant Script 4. Run Build
  46. 46. CruiseControl <ul><li>http://cruisecontrol.sourceforge.net/ </li></ul><ul><li>Interfaccia Web per monitorare il processo di build </li></ul><ul><li>Si integra con ANT, CVS e altri sistemi di source control </li></ul><ul><li>Notifica con email a responsabili di progetto e di modulo se una compilazione/test fallisce </li></ul>
  47. 47. Come funziona CruiseControl
  48. 48. DEMO <ul><li>Test LocalDbExplorer </li></ul><ul><li>con ANT e CruiseControl </li></ul>
  49. 49. Conclusioni <ul><li>“ Any program feature without an automated test simply doesn’t exist.” from Extreme Programming Explained, Kent Beck </li></ul>
  50. 50. Di cosa abbiamo parlato...
  51. 51. Riferimenti 1/2 <ul><li>Le slides di Bruno Bossola (JugTorino) al webbit 03: http://www.jugtorino.it/vqwiki/jsp/Wiki?LeSlideDelWebbit </li></ul><ul><li>http://www.mokabyte.it </li></ul><ul><li>Ingegneria del Software – Maurizio Pizzonia http://www.dia.uniroma3.it/~pizzonia/swe/ </li></ul><ul><li>Ingegneria del Software – Paolo Merialdo </li></ul><ul><li>http://www.dia.uniroma3.it/~merialdo </li></ul><ul><li>http://www.martinfowler.com </li></ul><ul><li>http://www.javaworld.com </li></ul><ul><li>http://www.wikipedia.org/ </li></ul>
  52. 52. Riferimenti 2/2 <ul><li>Cos’è XP http://www.xprogramming.com/xpmag/whatisxp.htm </li></ul><ul><li>http://www.pairprogramming.com </li></ul>

×