Workshop: Introduzione ad TDD
•Download as ODP, PDF•
0 likes•307 views
Una primissima introduzione al TDD per chi è a digiuno di test in generale e di TDD in particolare. Usa Java/Junit, ma è facimente adattabile ad altri linguaggi. 40-60 minuti.
Report
Share
Workshop: Introduzione ad TDD
- 1. METODOLOGIE AGILI Introduzione al workshop sperimentale
- 2. Fasi dello sviluppo software Analisi dei requisiti Progettazione Codifica Testing Rilascio
- 3. Sviluppare software è complesso Cosa il cliente veramente voleva
- 6. Limiti del waterfall Tende ad essere rigido e non adattabile
- 7. Tutto nel software cambia Requisiti Progetto Business Tecnologia Team
- 8. Gestire il cambiamento Il problema non è il cambiamento ma è l'incapacità di gestirlo
- 9. Obiettivi delle metodologie agili
- 10. Obiettivi delle metodologie agili Soddisfare il cliente per mezzo di tempestivi e continui rilasci di software di valore. I cambiamenti nelle specifiche sono ben accetti, anche a stadi avanzati di sviluppo. Ridurre i tempi di realizzazione Aumentare la produttività Aumentare la qualità Del software Del lavoro
- 11. Principi fondamentali dell'agile Lavoro di squadra Comunicazione Feedback continuo Piccoli passi
- 12. Molteplici tecniche e metodi
- 13. So what? Molte di queste tecniche sono considerate difficili Non si insegnano neppure all'università Richiedono mesi di addestramento Ecchecistiamo a fare qui?
- 14. Vogliamo cambiare! Non sempre quello che tutti pensano è la cosa giusta. Se non si fanno cambiamenti, non ci si evolve e crederemmo di sapere cose non proprio corrette:
- 15. Dove vogliamo andare? Vogliamo esporre programmatori giovani (”puri”?) precocemente a queste tecniche E’ nostra opinione che questo abbia un effetto positivo sul processo di sviluppo, in particolare sui programmatori Specialmente, pensiamo sia un’ottimo strumento didattico.
- 16. Cosa non è Non è una gara, tipo le Olimpiadi di Informatica Non deve essere stressante, semmai il contrario Non è una verifica. Se ci sarà il voto, sarà basato sulla cooperazione dimostrata, non sul codice prodotto. Non è neppure una lezione autoconclusiva. Applicheremo questa tecnica anche in futuro. ”Practice make perfect”.
- 17. Come lavoreremo Oggi proveremo ad applicare alcune tecniche agili tutte in una volta. Sarete divisi in gruppi di studio, ognuno dei quali lavora separatamente; però, la comunicazione con gli altri gruppi non è vietata (infatti, non è una gara). Proveremo a costruire una classe Java perfettamente (?) funzionante
- 18. 1° tecnica: Pair programming ? Se non lo conoscete già...
- 20. 2° tecnica: Timeboxing C'è un tempo ben determinato per chiudere un passo dello sviluppo Finito il tempo, si consegna. Niente eccezioni!
- 21. 3° Test Driven Development Prima si scrive il test Poi si scrive il codice Quando va, si migliora il codice
- 22. TDD – Scrivere il test Il test va scritto sapendo COSA si vuole ottenere, ma non come. Lanciare il test: DEVE fallire
- 23. TDD – Refactoring Scrivere il codice Scrivere il MINIMO codice che permette di passare il test Lanciare il test – se è rosso, rivedere il codice e ripetere
- 24. TDD – Refactoring Consiste nel modificare la struttura interna di un codice codice senza modificarne il comportamento esterno Permette di migliorare – la leggibilità – la riusabilità l'estensibilità – Le prestazioni
- 25. Argomento: Anno bisestile (WP) Un anno bisestile è un anno solare in cui avviene la periodica intercalazione di un giorno aggiuntivo nell'anno stesso, un accorgimento utilizzato in quasi tutti i calendari solari (quali quelli giuliano e gregoriano) per evitare lo slittamento delle stagioni: ogni 4 anni accumulerebbero un giorno in più di ritardo. Per correggere questo slittamento, agli anni "normali" di 365 giorni (ogni 4 anni) si intercalano gli anni "bisestili" di 366:
- 26. TEST DRIVE Proveremo un TDD con Junit – NON SCRIVERETE I TEST, ma vi limiterete a scrivere diretti dalle indicazioni del test. Sedetevi alle vostre postazioni Create un progetto Java Console e chiamatelo JavaBisestile. Creerà una classe chiamata JavaBisestile, all'interno del package javabisestile.
- 27. Step 1 - Setup Fate click destro sul file JavaBisestile.java Scegliete “Tools > Create Tests” Scegliete Junit 4.x. Il sistema creerà un file speciale, chiamato JavaBisestileTest.java Contiene lo scheletro del nostro test.
- 28. Step 1 – Test (RED + Green) Fate Run->Test Project Il risultato è rosso. Andate in JavaBisestileTest Eliminate la riga con throw... Fate Run->Test Project Verde!
- 29. Step 2 – First real test (RED)! In fondo alla classe JavaBisestileTest, ma prima dell'ultima graffa, aggiungete questo codice (Test1.java): @Test public void testIsBisestile() { assertTrue("2004 deve essere bisestile",JavaBisestile.isBisestile(2004)); assertTrue("2008 deve essere bisestile",JavaBisestile.isBisestile(2008)); assertTrue("2012 deve essere bisestile",JavaBisestile.isBisestile(2012));} Lanciate il test
- 30. Step 2 – First real test (RED)! Click sulla lampadina dell'errore Scegliete “Create Method isBisestile(int) in javabisestile.JavaBisestile”. static boolean isBisestile(int i) { throw new UnsupportedOperationException("Not supported yet."); } Lanciate il test (ancora rosso)
- 31. Step 2 – First real test (GREEN) Eliminare la riga fail(...)... Scrivere il codice minimo che renda valido il test Avete 20 secondi Lanciate il test: deve essere verde.
- 32. Step 2 – Controllo La soluzione corretta è return true In tutti gli altri casi avete agito con overcoding. Ricordate: scrivere il MINIMO codice che fa passare il test. In questo caso salteremo il refactoring
- 33. Step 3 - ”Triangulation” Il test che abbiamo aggiunto non è molto significativo Come nel caso della navigazione, per fare il punto abbiamo bisogno almento di un altro test, possibilmente che ci dica qualcosa di più. Per esempio elementi di tipo DIVERSO dal precedente. In gergo si chiama ”triangolazione”
- 34. Step 3 – Better test (RED) Inserite questo nuovo test (test2.java) @Test public void testNonBisestile() { assertFalse("2005 non deve essere bisestile",JavaBisestile.isBisestile(2005)); assertFalse("2003 non deve essere bisestile",JavaBisestile.isBisestile(2003)); assertFalse("2002 non deve essere bisestile",JavaBisestile.isBisestile(2002)); assertFalse("2001 non deve essere bisestile",JavaBisestile.isBisestile(2001)); }
- 35. Step 3 – Better test (GREEN) Fate in modo che il test passi Avete 120 secondi Lanciate il test: il test deve essere verde.
- 36. Step 3 – Better test (REFACTOR) Dedicate 130 secondi a migliorare il vostro codice Commenti? Javadoc? Nomi di variabili sensati? Indentazione? Fa schifo? – Usa uno switch? – Peggio, usa 4 if? – Se si è ora di cambiarlo (pensate a un test con 35 valori di anno...il vostro codice diventa elefantiaco) Dopo la correzione, tutto deve essere verde.
- 37. Step 4 – Non va ancora bene... Da Wikipedia: ”A partire dal 1582 è in funzione il calendario gregoriano, che elimina un anno bisestile all'inizio di ogni secolo, se non è divisibile per 400” Codifichiamo questo in un altro test.
- 38. Step 4 – Second test (RED) @Test public void testcalendarioGregoriano() { assertTrue("1000 non deve essere bisestile",JavaBisestile.isBisestile(1000)); assertFalse("1800 non deve essere bisestile",JavaBisestile.isBisestile(1800)); assertFalse("1900 non deve essere bisestile",JavaBisestile.isBisestile(1900)); assertTrue("2000 deve essere bisestile",JavaBisestile.isBisestile(2000)); }
- 39. Step 4 – Second test (RED) Finite il test nei tempi che desiderate Un premio a chi finisce prima con il codice migliore! File: Test3.java
- 40. Fine! Grazie per l'attenzione Pronti per l'azione ”vera”?