Considerazioni generali

In questo capitolo verranno discusse le motivazioni che ci hanno spinto ad adottare vari metodi di testing automatizzato ed i loro ambiti di impiego.

2.4.1.1 Testing come strumento di debugging

Durante la fase di sviluppo occorre eseguire certi passaggi anche diverse decine di volte in modo da vedere ripetutamente il comportamento del codice scritto ed aggiustare progressivamente l’implementazione fino al raggiungimento di quello atteso.

Nel contesto delle SPA, il solo fatto di raggiungere il passaggio sottoposto ad esame pu`o richiedere molti sforzi.

Nelle applicazioni di questo tipo un determinato scenario corrisponde ad una parti- colare configurazione dello stato interno. Salvo casi particolari, questo non pu`o essere raggiunto in maniera diretta dallo stato di default, ma occorre operare una serie di transizioni ammissibili. Per ognuna di queste occorre fornire dati in input vali- di ed evitare percorsi che produrrebbero side-effects tali da inficiare sullo scenario da sottoporre ad esame.

Nel caso in cui lo scenario da verificare richieda un contesto vergine, bisogna pure provvedere a ripulire gli effetti delle attivit`a precedenti prima di avviare ogni processo di debugging.

Il fatto di riequilibrare la proporzione tra attivit`a manuali di contorno al- lo sviluppo e lo sviluppo stesso `e stata la motivazione principale che ci ha spinto all’adozione di procedure di test automatiche.

Developer

Application App step: Application App step: Test Script TEST RUNNER La procedura automatizzata realizza il contesto necessario per debuggare la feature in sviluppo Lo sviluppatore si ritrova il sistema già nella precondizione ottimale e può concentrarsi sullo

sviluppo

DEBUGGER

Figura 2.29: Testing automatizzato come strumento per portare in maniera efficiente il sistema nello stato necessario per portare avanti lo sviluppo.

Questa metodica permette allo sviluppatore di lavorare con pi`u qualit`a perch´e deve concentrarsi solo sull’implementazione e non deve pi`u interrompere il processo creativo per ricreare la condizione di cui necessita.

Il fatto di ridurre il costo della fase di debug, permette di farne un uso pi`u frequente. In questo modo il software che esce dalla fase di sviluppo `e gi`a stato sottoposto ad un testing pi`u estensivo e richiede meno lavoro in fase di validazione.

2.4.1.2 Testing come strumento di validazione

Testare un sistema significa verificare che questo si comporti come atteso. Testare ogni feature, per ogni piattaforma ad ogni rilascio diventa una procedura impossibile da portare avanti manualmente.

Per supportare un sano percorso di validazione occorre adottare test automatizzati. L’automazione rende il costo di questa fase minimo, quindi ripetibile ogni volta che si sta per effettuare un rilascio o ogni volta che l’operato di un addetto `e stato integrato con quello del resto del team.

Per quanto sia indiscutibilmente utile avere la possibilit`a di verificare che i nuovi sviluppi non abbiano introdotto regressioni e che il lavoro in team non abbia portato a problemi di integrazione, non `e facile introdurre questa metodica.

Le procedure di test sono di fatto codice, quindi serve codice per testare il codice. Gli autori delle suite devono avere una perfetta conoscenza delle specifiche e ad ogni cambio di quest’ultime anche i test devono essere aggiornati.

In molti casi mettere in piedi un sistema di testing automatizzato, congetturare cen- tinaia di scenari che mettano alla prova il software e codificarli nella forma di tests, richiede un ordine di sforzo ben maggiore di quello di tradizionale manuale.

Il vantaggio dell’approccio automatico si manifesta solo sul lungo periodo o quando il numero di features `e molto alto o quando la frequenza dei rilasci `e molto alta.

Il nostro progetto non ricadeva perfettamente in nessuna di queste situazioni quindi abbiamo dovuto fare un compromesso.

La scelta `e stata quella di coprire con procedure di test solo le porzioni del sistema pi`u critiche e quelle che in caso di errori non avrebbero reso il fatto particolarmente manifesto. In questo modo abbiamo aggiunto un livello di garanzia maggiore a quei componenti per cui difficilmente ci sarebbe potuta pervenire una segnalazione di bug.

In riferimento alla procedura di registrazione: se ci fosse un bug in quella fase il contribuente non avrebbe modo di segnalare il malfunzionamento (perch´e ancora non ha accesso ad un canale di dialogo con lo staff) e noi non avremmo modo di accorgercene perch´e appunto, l’operazione `e avvenuta come guest e non ha lasciato impronta.

Questo ed altri flussi chiave sono stati coperti da procedure di testing auto- matizzate end-2-end in grado di simulare l’utente dalla sua registrazione al download del definitivo. Queste vengono lanciate a titolo di validazione prima di ogni rilascio importante.

2.4.1.3 Testing a titolo di specifica

I framework che abbiamo impiegato per scrivere i test abbracciano la metodologia Agile nella sua espressione Behavior Driven Development (BDD) [8].

L’idea di fondo `e quella di riconciliare le differenze tra il team tecnico e quello di management durante il processo di sviluppo. Nonostante nel nostro caso non ci sia questa distinzione tra teams (perch´e la nostra `e una piccola azienda) la metodica `e ugualmente significativa. Lo stesso autore di una specifica potrebbe dimenticarla nel tempo ed avere uno strumento conciso che permetta di storicizzarla e condividerla `e di valore oggettivo.

I test sono scritti in modo da descrivere la feature attraverso una sequenza di affermazioni riguardo cosa essa deve fare. Questi test devono intramezzare alle procedure codificate fasi descrittive che ne indichino l’intento ed il risultato atteso, in questo modo il lettore di un test pu`o dedurre la specifica del sistema.