lunedì 12 gennaio 2015

Il principio di VERITA - parte I

Una corretta ingegneria di un sistema di test in grado di abilitare l'uso delle metodologie agili deve rispettare alcuni principi base. Per facilitare la memorizzazione di questi principi è opportuno, talvolta, utilizzaredegli acronimi. Quello di cui parlerò oggi è VERITA. Un sistema di test agile deve essere impostato secondo il principo di VERITA. Vediamo cosa significa:

VERITA

Seguendo i dettami del principio di verità, i test devono essere:

Veloci,
Eseguibili
Ripetibili
Isolati,
Tempestivi
Autovalidanti

Vediamo, punto per punto, cosa significa applicare questo principio.

Veloci

Una Test Suite per un'applicazioni di medie dimensioni può comprendere anche diverse migliaia di Test Unit. Se ogni test unit dovesse impiegare anche solo un secondo per essere eseguita, una Test Suite potrebbe richiedere più di un'ora. Il risultato sarebbe l'abbandono "de facto" della metodologia. Per evitare di sprecare ogni giorno più del 10% del proprio tempo i programmatori finirebbero col far girare solo le Unit più recenti, quelle che riguardano il solo codice in corso di sviluppo, dove più alto è il livello di attenzione.

Risultato: le regressioni sarebbero scoperte solo molto tardi, nello sviluppo. Se anche le cose fossero messe meglio, diciamo 3000 Unit Test da 100ms, sarebbero comunque 300 secondi, pari a 5 minuti. O avete un team di caffeinomani, oppure non riuscirete a convincere i vostri programmatori a interrompere le attività più volte al giorno ed aspettare 5 minuti perchè una Test Suite termini. Nessuno aspetta 5 minuti più volte al giorno.

Una corretto approccio Test Driven richiede che si scriva un po' di codice, poco, e che immediatamente si testi l'intera applicazione. Cercare di accumulare una grossa quantità di modifiche prima di eseguire i test porta a due comportamenti, entrambi deprecabili:
  1. viene committato (e/o pullato) codice non testato nel sistema di versioning, rendendo instabile l'ambiente di sviluppo condiviso;
  2. viene committato (e/o pullato) codice a grossi blocchi, complicando il merge e, di nuovo, rendendo instabile l'ambiente.
C'è poco da fare, l'unica soluzione è rendere veloci i test. Per ottenere questo risultato è indispensabile eliminare ogni dipendenza dei test da sottosistemi intrinsecamente lenti, come possono essere:
  1. database di vario tipo, NoSql compresi
  2. connessioni in rete aventi tempi di risposta impredicibili, come sono spesso i web service
  3. sistemi remoti che espongono API che erogano servizi in modo lento o impredicibile
Il primo compito di uno sviluppatore, quindi, sarà di minimizzare la dipendenza dei propri test da sistemi di questo tipo. La domanda, a questo punto, sorge spontanea.

"Ma se devo evitare di mettere sotto test le aree dei programmi che fanno accesso a sottosistemi esterni, come faccio a testare quelle parti dell'applicazione in cui vengono gestite proprio le interfacce?"

Vedremo in una specifica serie di post come risolvere questo problema tramite i Mock. Intanto facciamo proprio il primo principio, e impegnamoci a creare test veloci, eseguibili in al massimo poche decine di millisecondi, cercando di dare comunque la massima copertura funzionale del codice ma evitando di finire imbottigliati in dipendenze lente e imprevedibili.

Nessun commento: