Glosario · Fundamentos de testing
Pruebas de caja blanca
En inglés: White-box testing
También llamado: prueba de caja blanca, caja blanca, pruebas estructurales, pruebas de caja de cristal
Definición
Pruebas diseñadas a partir del conocimiento del código interno, como sus ramas, condiciones y caminos, para asegurar que la implementación se comporta correctamente.
Las pruebas de caja blanca (white-box testing) diseñan los tests leyendo el código. El tester (a menudo el propio desarrollador) examina las ramas, las condiciones, los bucles y el manejo de errores, y escribe tests que los ejercitan de forma deliberada. También se llaman pruebas de caja de cristal, de caja transparente o pruebas estructurales. Los tests unitarios son su forma más común, y la cobertura de código es su medida habitual.
Ejemplo
String grade(int score) {
if (score < 0 || score > 100) {
throw new IllegalArgumentException("score out of range");
}
if (score >= 50) {
return "PASS";
}
return "FAIL";
}Al leer el código ves tres resultados (excepción, PASS, FAIL), y el primer if tiene dos condiciones separadas que pueden provocar cada una la excepción. Tests elegidos a partir de la estructura:
| Entrada | Camino ejercitado |
|---|---|
| -1 | score < 0 verdadero, excepción |
| 101 | score > 100 verdadero, excepción |
| 50 | dentro de rango, score >= 50 verdadero, PASS |
| 49 | dentro de rango, score >= 50 falso, FAIL |
Estos tests dan cobertura completa de ramas y de condiciones. Probar exactamente 50 y 49 también detecta un >= escrito por error como >.
Caja blanca frente a caja negra
La caja blanca pregunta “¿se comporta correctamente cada camino de este código?” y necesita el código fuente. La caja negra pregunta “¿hace el sistema lo que dicen los requisitos?” y solo necesita la especificación. La caja blanca encuentra caminos sin probar, código muerto y errores de lógica en las ramas. La caja negra encuentra funcionalidades que faltan y comportamientos que contradicen los requisitos, algo que la caja blanca no puede ver porque no existe código para una funcionalidad ausente. Las buenas suites usan ambas.
Límites
- Los tests pueden copiar los errores del código. Si el desarrollador entendió mal el requisito, los tests escritos a partir del código confirmarán el comportamiento equivocado.
- Acoplamiento fuerte. Los tests que dependen de métodos privados o de la estructura interna se rompen con cada refactorización aunque el comportamiento no cambie. Prueba a través de las interfaces públicas siempre que sea posible.
- Cobertura no es corrección. Ejecutar todas las ramas no dice nada sobre si las aserciones tienen sentido.