TDD Casi Studio
0 likes•235 views
Il documento analizza l'adozione dei test automatici nell'industria software, confrontando approcci come TDD e metodi tradizionali. Diversi esperimenti industriali e accademici mostrano che il TDD migliora la qualità del design e la produttività, nonostante possa richiedere più tempo. Si concludono i benefici degli unit test, come la riduzione dei bug di regressione e la facilitazione del refactoring.
TDD Casi Studio
- 1. Analisi di dati statistici sull'adozione di Unit Test nell'industria software.
- 2. Esperimento 1: TDD vs Waterfall Esperimento Industriale Progetto: 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 Team Development 116% 100% time Functional 118% 100% black box test passed
- 3. Esp 2: TDD vs altri metodi Esperimento Industriale Progetti: Applicazione C++ e C# Contesto: Specifiche fornite. 2 gruppi seguono TDD 2 gruppi non seguono TDD. LOC = Lines Of Code Block Coverage = Lines Of Code / Exercised lines of code
- 4. Esp 3: TDD vs Test Last Gruppo “TDD” e gruppo “Test Last” Produttività identica Gruppo “TDD” produce più test e li esegue più spesso. Esperimento Industriale Progetti: Piccola applicazione (90/100 min) Contesto: 1 gruppo Test First 1 gruppo Test Last
- 5. Esp 4: TDD vs Test Last TDD Richieste maggior tempo di sviluppo Il miglioramento in qualità supera il maggior tempo di sviluppo TDD fa si che il design sia Più preciso Casi di test più accurati Esperimento Industriale Progetti: Breve task di implementazione di circa 5 ore Contesto: Primo task con TDD Secondo task waterfall
- 6. Esp 5: TDD vs Test Last TDD Nessun incremento della velocità di sviluppo Nessun incremento della qualità Esperimento Accademico Progetti: Implementare il corpo di metodi Contesto: Primo task con TDD Secondo task senza TDD
- 7. Esp 6:TDD vs Last Test vs No Test I risultati indicano che TDD può essere Un approccio al design Migliora la decomposizione degli oggetti Incrementa la copertura dei test Incrementa la qualità esterna Aumenta la produttività Aumenta la confidenza Esperimento Accademico Progetti: 70 / 190 ore uomo Contesto: 1 gruppo TDD 1 gruppo Test Last 1 gruppo no Test
- 8. Esp 7:TDD vs Last Test Risultati Gli studenti che hanno praticato TDD scrivono più unit test Gli studenti che scrivono più test tendono ad essere più produttivi Esperimento Accademico Progetti: Segnapunti bowling Contesto: 1 gruppo Test First 1 gruppo Test Last
- 9. Esp 8: IBM Pos Sistema POS Numerose release Release 0 senza test
- 10. Esp 8: IBM Pos 5 moduli con defect density maggiore defect density = defects / loc 5 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 derivanti dall'adozione 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 l'adozione naturale di buone tecniche OOP.
- 16. Contesti controproducenti Contesti causati da fattori umani: Errata confidenza negli Unit Test. Gli Unit Test sono solo uno strumento Errate attese: Unit Test non testano l'applicazione, ma i singoli componenti. Unit Test controproducenti durante gli spike tecnici o proof of concept Preferire gli Integration Test agli Unit Test per evitare il ricorso ai Mock.
- 17. Criticità Ecosistema di supporto Umano Volontà degli sviluppatori Spinta del management Bugfixing attraverso la riproduzione del bug con uno unit test Tecnologico IDE per feedback immediato: green / red bar Continuous Integration: validità dei test Test Coverage: indice per i nuovi test