Software testing: alcuni chiarimenti
Scrivere bene i test non è scontato, non basta scriverne tantissimi o avere un’alta percentuale di coverage (1). Quando ciò accade, il più delle volte è perché ci sono molti test inutili o scritti male. Certo, pochi test o una coverage bassa (sotto il 50%) sono sintomo di bug, ma non vale il contrario perché è molto facile ottenere numeri alti con test di poca o addirittura nulla utilità. La coverage va usata per capire quali sono i punti nel nostro codice dove i test scarseggiano e quello a cui dovremmo puntare non è avere tanti test, ma averne di qualità.
Eppure i test sono il “coltellino svizzero” dello sviluppatore:
- Danno un feedback rapido e automatico per salvarvi dal rilasciare bug in produzione.
- Permettono di mettere mano a codice scritto da altri e che non conoscete, senza il rischio di fare troppi danni.
- Consentono di modificare il tanto temuto “codice legacy”, perché scrivere tanti test potrebbe essere la vostra unica ancora di salvezza. A tal proposito, conoscete la tecnica del Golden Master Testing (2)?
- Possono guidarci nello sviluppo di nuove funzionalità, come TDD (3) ci insegna
- Permettono di fare refactoring di codice, attività che, senza una copertura di test, non potreste fare limitandovi quindi a quelli automatici offerti dal vostro IDE.
- Aiutano a migliorare il design del codice: scrivendo uno unit test e facendo fatica a concepirlo, vi accorgete di come modificare il codice dell’applicazione riducendone/spostandone la complessità per aiutarvi a scrivere il test; questo forza a rivedere e migliorare il design.
- Possono diventare la migliore documentazione per il vostro codice: leggerli vi aiuta a capire meglio le funzionalità e i casi d’uso previsti.