Voglio fare una classifica della 3-giorni dell'evento Microsoft Visual Studio
Team System a cui ho potuto prendere parte grazie all'invito di Lorenzo.
- Martedì 30 maggio, dedicata al Team System for Software
Developers
(unit-testing, code-coverage e dintorni)
- La mattinata del 31 maggio, dedicata alla teoria del buon
testing
(investire sulla prevenzione del bug, )
- Lunedì 29 maggio, dedicata al Team System for Software
Architects
(diagrammi vivi per progettare l'infrastruttura
distribuita nella quale gireranno le nostre apps)
- Il pomeriggio del 31 maggio, dedicata a test di
applicazioni Web
(c'è bisogno di ricordare che non me ne frega
nulla? 
)
La medaglia d'oro se la aggiudica di gran lunga il Team System dedicato
agli sviluppatori, perchè mi hanno esaltato lo unit-testing e il code-coverage
unito alle potenzialità comuni alle diverse versioni di Team System. Mi è molto
piaciuta anche la mattinata di ieri, dove abbiamo affrontato tutta la teoria
riguardante il testare un software, indipendentemente dallo strumento
offerto.
Punti essenziali
Il test è una questione che riguarda
tutto il ciclo di sviluppo di un software, e riguarda tutto il team coinvolto:
dallo sviluppatore a tutti gli altri. Il test è un'attività simile a tutte le
altre: va pianificata, monitorata e tenuta sotto controllo. Bisogna
pensare a quali parti del software testare, una questione che ogni tanto mi
prende buona parte del mio tempo: la mia opinione personale è che occorre considerare quali parti di un software saranno maggiormente
riutilizzabili (se trovo un bug nella versione 1.0, tale bug si
ripercuoterà nelle x versioni successive) e quali
parti sono maggiormente critiche rispetto ad altre.
Mi viene da pensare, per esempio, alla UI di un'applicazione. Difficilmente
rimarrà la stessa a lungo, tendenzialmente ad ogni release c'è sempre
un processo di ammodernamento per allinearsi ai nuovi standard dettati,
nel nostro caso, da Microsoft. Pensiamo a Word: se dovessi decidere io, mi
interesserebbe molto di più verificare l'affidabilità dell'object model, perchè
magari questo me lo trascino da una release all'altra. La UI invece subisce
stravolgimenti ogni volta.
Parlando nel mio piccolo, mi interessa poter affermare che i miei business
object siano il più possibile esenti da errori: mi interessa sapere che la
proprietà read-only TotaleFattura ritorni davvero il totale
dell'importo della fattura. Oppure, che quando elimino tutte le istanze di
RigaFattura, il totale della fattura diventi 0. Se i miei
business object si comportano correttamente, sono già ragionevolmente sicuro che
buona parte dell'applicazione gira bene. Osservazione importante: se un giorno
volessi migrare la mia applicazione su altre tecnologie (ASP.NET,
Windows Presentation Foundation, tanto per dirne un paio), il domain model
rimane sempre quello: se è esente da bug, ho tutto da guadagnarci. Questo si
riflette su un'altro punto citato ieri da Lorenzo: prima si trova un bug, minori
sono i costi richiesti per fissarlo. Se trovo un bug durante le fasi iniziali
di sviluppo (come durante il disegno del domain model), è molto meglio che
trovarlo quando il cliente chiama e ci dice: "Uè, nelle
Fatture il totale è sempre sballato, ma quell'importo è quello con iva o quello
senza? cos'è????".
L'altro punto è sulla criticità di una certa
parte di codice. Con unit-testing non mi interessa testare il
get;set; di ogni singola property delle mie classi, ma magari le property in
read-only che ritornano un risultato calcolato, o magari i salvataggi su
database, oppure metodi che fanno calcoli matematici che impattano poi sul
data-binding con Windows Form, sulla reportistica, ecc. ecc. Le parti
critiche sono quelle parti del codice che vanno ad impattare sul funzionamento
di altro codice. Indiana Jones diceva che la X indica il punto dove scavare.
Questa regola andrà bene per gli archeologi, ma non per noi sviluppatori:
la linea sottolineata in rosso non sempre è la linea che
contiene l'errore vero e proprio. Come ha detto Lorenzo,
l'errore molto spesso è da qualche parte prima rispetto a quella linea; bisogna
quindi risalire il codice e vedere davvero dove si è innescato il meccanismo
perverso che ha portato all'eccezione. Ecco il codice critico!