No olvides que en las ciencias informáticas cualquier problema casi siempere suele tener diversas soluciones, de igual modo aquí enseñamos lo más óptimo y mejor.
Solución:
Creo que este artículo de Kent Beck se refiere más a TDD y pruebas unitarias lo resume bastante bien. Básicamente, depende de cómo escribas realmente las pruebas *. Aquí hay otro artículo sobre el tema que podría ayudar a aclarar las cosas.
* Si está probando desde dentro de su aplicación, entonces es whitebox. Si lo está probando como si un extraño hiciera las llamadas solo a su API pública, entonces es una caja negra.
El criterio habitual para las pruebas de caja blanca es la ruta de ejecución y la sensibilización de la estructura de datos. A veces, se denominan “pruebas de rama”, “pruebas de ruta”, “pruebas de flujo de datos”. Consulte Wikipedia sobre pruebas de caja blanca.
Es decir, la prueba unitaria se refiere al nivel en el que tiene lugar la prueba en la estructura del sistema, mientras que las pruebas de caja blanca y negra se refieren a si, en cualquier nivel, el enfoque de la prueba se basa en el diseño interno o solo en la especificación externa de la unidad.
Entonces, si su prueba unitaria sensibiliza todas las rutas de ejecución y estructuras de datos en la unidad que está probando, entonces es una prueba de caja blanca. Sin embargo, si su unidad no puede sensibilizar la mayoría de las rutas y estructuras de datos de la unidad, entonces no puede pretender ser una prueba de caja blanca.
Tenga en cuenta que, en algunas organizaciones, las pruebas unitarias se denominan pruebas de caja blanca independientemente de si la prueba unitaria se basa en el diseño de la unidad en lugar de solo en su API. Es mejor no discutir con su jefe sobre este punto.
Recuerda algo, que puedes optar por la opción de añadir una estimación si encontraste tu obstáculo .