Oltre 1000 test per un gioco da hobby: uno spreco?

Il nostro progetto ha ormai ben oltre mille test automatici: circa 990 lato server, circa 120 nel client Unity. Per un progetto di famiglia sembra eccessivo. È il contrario, ed ecco perché.

I test sono il nostro secondo sviluppatore. In un progetto solitario non c'è nessuno che nella code review dica: «Aspetta, così si rompe il crafting.» I test sono quel collega. Ogni meccanica di gioco (ricette, ossigeno, fame, comportamento delle creature, password dei mondi) ha test che girano a ogni modifica. Rifattorizzare senza paura è il vero vantaggio.

Abbastanza veloci da non dare fastidio. I test che durano un quarto d'ora non li esegue nessuno. Per questo il nostro controllo CI è a due stadi: la verifica della pull request gira in circa tre minuti con i test veloci; la suite completa, lenta, parte dopo. Così il ciclo di sviluppo resta scattante senza perdere copertura.

Testare Unity è un argomento a parte. La logica del client è difficile da testare dentro un motore in esecuzione. Il nostro trucco: la logica centrale del client vive in una libreria a sé che gira senza Unity, e la testiamo in modalità headless come codice normale. Solo ciò che richiede davvero il motore gira come test EditMode/PlayMode.

I warning sono errori. La nostra CI compila con «warnaserror»: ogni warning del compilatore rompe la build. Sembra pedante, ma previene il cimitero dei warning in cui prima o poi affoga l'unico warning importante.

Il bilancio onesto: scrivere test costa forse un quinto del tempo di sviluppo. Ma ogni funzione corretta resta corretta, e per un progetto che prende vita la sera dopo il lavoro nulla vale di più della certezza che la funzione del fine settimana non abbia rovinato quella del martedì.