238 file di test: come si paga il debito tecnico senza fermare il team

01Il debito ha un tasso di interesse

La suite di test end-to-end di un frontend era rimasta su JUnit 4, senza Spring, con le configurazioni disseminate in più file e il ciclo di vita del WebDriver gestito a mano in ogni classe. Risultato: test lenti, fragili e che nessuno voleva toccare.

Il punto da far capire a chi decide non è «il codice è brutto», è che ogni sprint il team pagava ore in test instabili e diagnosi. Il debito tecnico si argomenta in tempo, non in estetica.

02Prima la roadmap, poi i file

Ho scritto una roadmap con l'ordine delle aree da migrare, il criterio di «fatto» per ciascuna e le best practice da seguire, e solo dopo ho distribuito i task. Un intervento di questa dimensione fallisce quasi sempre per mancanza di ordine, non di competenza.

La migrazione è andata a JUnit 5 con Spring per la dependency injection e per il ciclo di vita del driver, con le configurazioni centralizzate: 238 file feature toccati, area per area, con la suite sempre verde alla fine di ogni giornata.

03Parallelizzare è l'ultimo passo, non il primo

Parallelizzare test instabili moltiplica l'instabilità. Prima si rende ogni test indipendente dallo stato lasciato dagli altri, poi si attiva l'esecuzione parallela — nel nostro caso con Maven Surefire — e il tempo di suite crolla.

L'ordine conta: isolamento, poi velocità. Il contrario produce una pipeline rossa a caso, che è peggio di una pipeline lenta perché insegna al team a ignorarla.

04Il risultato che si può raccontare

Alla fine: debito ridotto in modo misurabile, tempi di esecuzione abbattuti, e soprattutto un team junior formato su una struttura che si spiega in mezz'ora. Questa è la parte che resta quando il progetto passa di mano.