1. Analisi di dati statistici sulladozione diUnit Test
nellindustria software. 2. Esperimento 1: TDD vs
WaterfallEsperimento IndustrialeProgetto: Applicazione Java per la
gestione del punteggio di una partita di bowling.Contesto:
Specifiche fornite. 2 gruppi seguono modello waterfall 1 gruppo
segue modello TDD. TDD Team Waterfall TeamDevelopment116%
100%timeFunctional 118% 100%black box testpassed 3. Esp 2: TDD vs
altri metodiEsperimento IndustrialeProgetti: Applicazione C++ e
C#Contesto: Specifiche fornite. 2 gruppi seguono TDD 2 gruppi non
seguono TDD.LOC = Lines Of CodeBlock Coverage = Lines Of Code /
Exercised lines of code 4. Esp 3: TDD vs Test LastGruppo TDD e
gruppo Test LastProduttivit identicaGruppo TDD produce pi test e li
esegue pi spesso.Esperimento IndustrialeProgetti: Piccola
applicazione (90/100 min)Contesto: 1 gruppo Test First 1 gruppo
Test Last 5. Esp 4: TDD vs Test LastTDD Richieste maggior tempo di
sviluppo Il miglioramento in qualit supera il maggior tempo
disviluppo TDD fa si che il design siaPi precisoCasi di test pi
accuratiEsperimento IndustrialeProgetti: Breve task di
implementazione di circa 5 oreContesto: Primo task con TDD Secondo
task waterfall 6. Esp 5: TDD vs Test LastTDD Nessun incremento
della velocit di sviluppo Nessun incremento della qualit
Esperimento Accademico Progetti: Implementare il corpo di metodi
Contesto:Primo task con TDDSecondo task senza TDD 7. Esp 6:TDD vs
Last Test vs No TestI risultati indicano che TDD pu essereUn
approccio al designMigliora la decomposizione degli
oggettiIncrementa la copertura dei testIncrementa la qualit
esternaAumenta la produttivitAumenta la confidenzaEsperimento
Accademico Progetti: 70 / 190 ore uomo Contesto:1 gruppo TDD1
gruppo Test Last1 gruppo no Test 8. Esp 7:TDD vs Last
TestRisultatiGli studenti che hanno praticato TDD scrivono pi
unittestGli studenti che scrivono pi test tendono ad esserepi
produttivi Esperimento Accademico Progetti: Segnapunti bowling
Contesto: 1 gruppo Test First 1 gruppo Test Last 9. Esp 8: IBM
PosSistema POSNumerose releaseRelease 0 senza test 10. Esp 8: IBM
Pos5 moduli con defect density maggiore defect density = defects /
loc5 moduli con defect density minore 11. Esp 8: IBM Pos 12.
Conclusioni 13. Conclusioni 14. perch dovrei usare gli unit test
?perch non li sto usando ? 15. Analisi dei vantaggi
derivantidalladozione degli Unit Test.Scrivere uno Unit Test test
significa pensare alle specifiche di funzionamento.Suite di Unit
Test, stimolando pi classi, limitano i bug di regressione a fronte
di nuovi sviluppi.Suite di Unit Test, stimolando pi classi,
permettono il refactoring: modifica del funzionamento interno
rispettando i contratti.La testabilit come forza che spinge verso
ladozione naturale di buone tecniche OOP. 16. Contesti
controproducentiContesti causati da fattori umani:Errata confidenza
negli Unit Test. Gli Unit Test sono solo uno strumentoErrate
attese: Unit Test non testano lapplicazione, ma i
singolicomponenti.Unit Test controproducenti durante gli spike
tecnici o proof of conceptPreferire gli Integration Test agli Unit
Test per evitareil ricorso ai Mock. 17. CriticitEcosistema di
supportoUmanoVolont degli sviluppatoriSpinta del
managementBugfixing attraverso la riproduzione del bug con uno
unittestTecnologicoIDE per feedback immediato: green / red
barContinuous Integration: validit dei testTest Coverage: indice
per i nuovi test
