Glossario · Fondamenti del testing
White-box testing (test a scatola bianca)
In inglese: White-box testing
Detto anche: test a scatola bianca, white box testing, test white-box, test strutturale
Definizione
Test progettati a partire dalla conoscenza del codice interno, come branch, condizioni e percorsi, per assicurarsi che l'implementazione si comporti correttamente.
Il white-box testing (test a scatola bianca) progetta i test leggendo il codice. Il tester (spesso lo sviluppatore) esamina branch, condizioni, cicli e gestione degli errori e scrive test che li esercitano deliberatamente. Si chiama anche glass-box, clear-box o test strutturale. Gli unit test ne sono la forma più comune e la code coverage è la sua misura abituale.
Esempio
String grade(int score) {
if (score < 0 || score > 100) {
throw new IllegalArgumentException("score out of range");
}
if (score >= 50) {
return "PASS";
}
return "FAIL";
}Leggendo il codice vedi tre esiti (eccezione, PASS, FAIL), e il primo if ha due condizioni distinte che possono ciascuna scatenare l’eccezione. Test scelti in base alla struttura:
| Input | Percorso esercitato |
|---|---|
| -1 | score < 0 vera, eccezione |
| 101 | score > 100 vera, eccezione |
| 50 | nell’intervallo, score >= 50 vera, PASS |
| 49 | nell’intervallo, score >= 50 falsa, FAIL |
Questi test danno una copertura completa di branch e condizioni. Testare esattamente 50 e 49 intercetta anche un >= scritto per sbaglio come >.
White-box e black-box testing a confronto
Il white-box chiede “ogni percorso di questo codice si comporta correttamente?” e richiede il sorgente. Il black-box chiede “il sistema fa ciò che dicono i requisiti?” e richiede solo la specifica. Il white-box trova percorsi non testati, codice morto ed errori di logica nei branch. Il black-box trova funzionalità mancanti e comportamenti in disaccordo con i requisiti, che il white-box non può vedere perché per una funzionalità mancante non c’è codice. Le buone suite usano entrambi.
Limiti
- I test possono copiare gli errori del codice. Se lo sviluppatore ha frainteso il requisito, i test scritti a partire dal codice confermeranno il comportamento sbagliato.
- Accoppiamento stretto. I test che dipendono da metodi privati o dalla struttura interna si rompono a ogni refactoring anche quando il comportamento non cambia. Dove possibile, testa attraverso le interfacce pubbliche.
- Coverage non significa correttezza. Eseguire ogni branch non dice nulla sul fatto che le asserzioni siano significative.