TEST DRIVEN DEVELOPMENT

Prima ancora che Joe iniziasse a costruire la macchina Wikispeed, iniziò a creando un modello per predire il consumo di carburante. Egli identificò più di 100 parametri già largamente noti, come il peso, il coefficiente di attrito, la potenza del motore, la dimensione delle ruote, ecc. Basandosi su questi parametri egli poteva prevedere il consumo di carburante dell’auto con un margine di errore minimo.

Con questo modello Joe calcolò non solo le caratteristiche che Wikispeed doveva avere in modo da non consumare più di un gallone per 100 miglia ma anche per avere caratteristiche degne di una macchina sportiva di alto livello.

Inoltre il team Wikispeed voleva ottenere l’equivalenza di cinque stelle al crash test secondo le specifiche NHTSA e IIHS. Queste specifiche impattano in diverse condizioni per valutare la resistenza delle auto agli impatti. Questi test erano estremamente costosi, circa 10.000 dollari a test, oltre al costo del veicolo stesso, il suo trasporto e lo smaltimento dei materiali, senza considerare le spese di viaggio del personale coinvolto. In che modo potevano evolvere il design ogni settimana quando ogni modifica strutturale richiedeva di ripetere questi test completamente?

Il primo passo ha richiesto di ridurre il numero di elementi da analizzare per simulare il crash test al computer. Quando il team ha ritenuto che il prototipo potesse superare il test lo hanno eseguito veramente. Chiaramente il primo test non è stato superato completamente, ma questo non era un problema. Il team Wikispeed voleva avere dei dati di un test reale in modo da migliorare il loro modello di simulazione. Aggiornando i coefficienti del simulatore con i dati reali permise di avere un test simulato molto più attendibile. Dopo alcune iterazioni il loro simulatore diventò così realistico che l’autorità di certificazione iniziò ad accettare i test simulati in luogo a quelli reali. Avendo un crash test quasi completamente automatico il team Wikispeed poteva ripeterlo ad ogni iterazione, ogni settimana.

Test Driven Development, qualità e aderenza ai requisiti by-design.

Per disegnare un nuovo componente, il team wikispeed:

1. Creavano il test che desideravano vedere superato. Poteva trattarsi anche di un test ad alto livello, come il tasso delle emissioni degli scarichi o un crash test, oppure un test unitario a livello di componente. Se era possibile, lo rendevano automatico in modo da abbattere il costo della ripetizione del test nelle successive iterazioni.
2. Creavano il più semplice design che permettesse di superare il test.
3. Iteravano il design, migliorandolo incrementalmente, finché non ritenessero il pezzo buono abbastanza.

Nel software, questo processo è conosciuto come “Luce Rossa, Luce Verde, Refactoring”. Per implementare qualcosa, prima viene creato un test che fallisce immediatamente (luce rossa). Dopodiché si implementa la funzionalità in modo da far superare il test (luce verde). Quindi si migliora il design per ottenere una migliore manutenibilità, efficienza, ecc. Questa fase è chiamata “refactoring”.