Come tecnici, spesso riscontriamo che lo sforzo di migliorarsi e di utilizzare metodi di sviluppo più moderni non è percepito dal proprio capo (o committente) come un vantaggio, quanto invece come un costo inutile. Vedremo quindi quali strategie adottare per introdurre l'uso degli unit test (e, più in generale, dei test automatici) nella propria routine di sviluppo quotidiana.

1. Come farsi autorizzare
gli unit test dal boss
Marco Amendola
marco.amendola@outlook.com
@marcoamendola
getlatestversion
ALM for Dummies
#ALM4Dummies

2. • Chi sa già cosa siano gli unit test?
• Chi già li utilizza nel proprio lavoro quotidiano?
Sondaggio
2

3. • A chi vuole iniziare ad usare unit test
• A chi vuole migliorare le pratiche
di sviluppo aziendali
• A chi lavora su progetti molto longevi
A chi si rivolge
3

4. A cosa servono gli unit test
• Verifica della correttezza del codice
• Rete di sicurezza
4

5. Rete di sicurezza
Diverse attività quando sviluppiamo
• Evoluzione/Correzione bug
• Nuove funzioni
• Ottimizzazione
• Refactoring
Evitare di modificare (involontariamente) i comportamenti del sistema
è il task maggiore
5

6. Ostacoli all’utilizzo degli unit test
• Scarsa conoscenza delle tecniche e manualità
• Pratica non presente nella cultura aziendale
• Spesso presentati in scenari «greenfield»
6

7. Approcci diversi
• Consulenti esterni
• Dipendenti (o interni)
Limiti
• Non c’è un metodo infallibile
• Ambito ristretto al proprio
potenziale di intervento
Cambiare la cultura aziendale
7

8. Convincere il boss
Come sviluppatori siamo
• dei nerd affascinati dalla tecnica
• poco abituati a vedere (o evidenziare!)
aspetti «business»
8

9. Parlare in modo comprensibile al «business»
Vantaggio tecnico Punto di interesse per il «business»
Diminuzione delle regressioni Diminuzione ore impiegate su:
• test pre-rilascio
• correzione anomalie
Ciclo di codifica, test e debug più rapidi e
meno noiosi
Risparmio dei tempi impiegati per:
• avvio applicazione
• autenticazione
• navigazione
• creazione caso
• test manuale
Base di codice ben strutturata e più facilmente
modificabile
Diminuzione ore impiegate per:
• manutenzione evolutiva
• istruzione nuovi dev
Miglior design del sorgente Maggior qualità dell’asset
9

10. Mantenere il passo
• Essere costanti
• Creare massa critica: gli sforzi sono velocemente superati dai risultati
• Ricercare altri sponsor interni
• Evidenziare risultati quantitativamente
10

11. Gestire il codice legacy
• Scappate!
Una cattiva codebase crea stress
• Attenti a dove scappate
I rifacimenti di un progetto sono il Vietnam dell’IT
Il nuovo codice diventa comunque legacy (in fretta!)
• Trasformate il codice legacy in codice testato
Da «Edit & Pray» a «Cover & Modify»
11

12. Poco convinti?
• Spesso ci si lamenta del progetto poco «cool»,
ma si continua a peggiorarlo
• E’ un processo lento ma le modifiche tendono
ad ammassarsi in punti vicini
• E’ un approccio applicabile anche con ambienti
e tool vecchi
• Si usano tecniche interessanti
• Si riduce lo stress da incertezza
12

13. • Identificare il punto da modificare
• Istanziare la classe nel test
• Isolare le dipendenze da altre classi e servizi esterni
• Difficile eseguirli nel test
• Diventa un test di integrazione
• «Certificare» il comportamento attuale
• Verifica stato
• Sondaggio attraverso fake/mock
• Effettuare la modifica
Metodologia generale
13

14. • Dipendenze funzionali e temporali
• L’ordine non deve essere importante
• Bisogna «ricostruire» il mondo ad ogni test
• Test troppo grandi
• Non si trova in fretta la causa di errori
• Ma neanche insignificanti!
• Test molto lenti
• Meglio se <10ms, con eccezioni
Da evitare
14

15. Con moderazione
• Test contro basi dati
• Male necessario
• Rigenerazione dei dati
• Ripristino da backup
• Test di gruppi articolati di classi
• Test di integrazione
15

16. Consigli
• «Fotografare» output attuale
• Approval test
• Migliorare la copertura appena possibile
• Suddividere i test per tempo di esecuzione
• Lo scopo è far girare almeno un gruppo
di test continuamente
16

17. Takeaway
• Sottolineare aspetti quantitativi
• Non «bruciare» il tema, magari iniziare senza chiedere
• Contribuire con un investimento di tempo
• 10% = 30’ su 4h
• Insistere: i vantaggi sono notevoli
• Per mettere i codice sotto test sono
costretto a migliorarlo
• Si riduce il timore di errori e lo stress
17

18. Libri da leggere
• Working Effectively with Legacy Code (Michael Feathers)
http://bit.ly/alm4d-test-1
• The Art of Unit Testing (Roy Osherove)
http://bit.ly/alm4d-test-2
18

19. Sponsor
19

20. Feedback form
20
Marco Amendola
marco.amendola@outlook.com
@marcoamendola
http://svy.mk/1BLujLb