Glossaire · Fondamentaux du test
Test boîte blanche
En anglais : White-box testing
Également appelé : test en boîte blanche, tests boîte blanche, test structurel, test boîte de verre
Définition
Tests conçus à partir de la connaissance du code interne, comme ses branches, conditions et chemins, pour s'assurer que l'implémentation se comporte correctement.
Le test boîte blanche (white-box testing) conçoit les tests en lisant le code. Le testeur (souvent le développeur) examine les branches, les conditions, les boucles et la gestion des erreurs, et écrit des tests qui les exercent délibérément. On parle aussi de test boîte de verre, boîte transparente ou de test structurel. Les tests unitaires en sont la forme la plus courante, et la couverture de code sa mesure habituelle.
Exemple
String grade(int score) {
if (score < 0 || score > 100) {
throw new IllegalArgumentException("score out of range");
}
if (score >= 50) {
return "PASS";
}
return "FAIL";
}En lisant le code, on voit trois issues (exception, PASS, FAIL), et le premier if comporte deux conditions distinctes qui peuvent chacune déclencher l’exception. Les tests choisis d’après la structure :
| Entrée | Chemin exercé |
|---|---|
| -1 | score < 0 vrai, exception |
| 101 | score > 100 vrai, exception |
| 50 | dans l’intervalle, score >= 50 vrai, PASS |
| 49 | dans l’intervalle, score >= 50 faux, FAIL |
Ces tests donnent une couverture complète des branches et des conditions. Tester exactement 50 et 49 détecte aussi un >= écrit par erreur >.
Test boîte blanche ou boîte noire
La boîte blanche demande « chaque chemin de ce code se comporte-t-il correctement ? » et nécessite le code source. La boîte noire demande « le système fait-il ce que disent les exigences ? » et ne nécessite que la spécification. La boîte blanche trouve les chemins non testés, le code mort et les erreurs de logique dans les branches. La boîte noire trouve les fonctionnalités manquantes et les comportements contraires aux exigences, que la boîte blanche ne peut pas voir puisqu’il n’existe pas de code pour une fonctionnalité absente. Les bonnes suites utilisent les deux.
Limites
- Les tests peuvent recopier les erreurs du code. Si le développeur a mal compris l’exigence, des tests écrits d’après le code confirmeront le mauvais comportement.
- Couplage fort. Les tests qui dépendent de méthodes privées ou de la structure interne cassent à chaque refactoring, même quand le comportement ne change pas. Testez via les interfaces publiques autant que possible.
- Couverture n’est pas exactitude. Exécuter chaque branche ne dit rien sur la pertinence des assertions.