Si probamos una función B, al probar una función C que llama a esa función B, es decir, escribir un programa de prueba para probar la función C que llama a esa función B, ¿el método de prueba todavía se llama prueba unitaria, o algo más?
¿Cuándo se prefiere probar indirectamente en una función que llama a la función objetivo, y cuándo se prefiere probar una función directamente?
Una definición popular de prueba unitaria es la de ISTQB:
Una prueba unitaria es la parte comprobable más pequeña de una aplicación, como funciones, clases, procedimientos e interfaces. Las pruebas unitarias son un método mediante el cual se prueban unidades individuales de código fuente para determinar si son aptas para su uso.
De acuerdo con esta definición:
Ahora puede haber una diferencia entre la intención y el alcance de la prueba. Si escribe un programa de prueba para B usando C, sigue siendo una prueba unitaria de C, porque todo lo que puede hacer es proporcionar la entrada a C y verificar en función de la salida si B fue correcto. Es solo que deduces que B funciona porque C funciona.
También hay una definición de prueba de integración :
Pruebas realizadas para exponer defectos en las interfaces y en las interacciones entre componentes o sistemas integrados.
La definición habitual de componentes de software implica que es independiente y puede implementarse por sí sola. Aquí, B y C parecen no ser componentes independientes, por lo que no tenemos una prueba de integración.
Esto depende mucho de lo que consideres una unidad. Si Ces tan simple que probarlo por separado no tiene sentido, entonces su prueba es una prueba unitaria.
Mucho más importante es que su conjunto de pruebas unitarias para una unidad en particular tenga una cobertura de línea cercana al 100% y que pruebe todas las rutas de código prácticamente anticipadas.
Sí, todavía lo llamamos prueba de unidad si las funciones llaman a otras funciones.
Las pruebas unitarias deben probar el comportamiento público de una clase y no las implementaciones privadas. Como lo sugiere esta prueba de Google en el artículo de aseo .
Si sigue las reglas de Clean Code , sus funciones no deberían ser más largas que 4 líneas de código. Esto hace que sea imposible no probar otra función privada con sus pruebas unitarias.
¿Por qué no debería probar la unidad de la mayoría de las funciones privadas por separado? Porque la refactorización lo obligaría a seguir actualizando todas sus pruebas unitarias de implementación. Esto será frustrante cuando tenga muchos de ellos, mientras que el comportamiento público no debería cambiar durante la refactorización y, por lo tanto, la prueba no debería necesitar ninguna actualización. Debería poder evaluar a los privados con sus padres públicos. A veces puede valer la pena probar complejos privados, pero se preguntan si deberían ser una clase separada por sí mismos
Prueba de integración :
Ahora, si la función es parte de otra clase, es diferente. Entonces lo llamaríamos pruebas de componentes o pruebas de integración. Estás integrando múltiples clases y ejecutando una prueba contra ellas. La función B dependería de la función C. Para poder realizar una prueba unitaria de la función B, podría usar la inyección de dependencia para aislar la función que está probando, ahora sería una prueba unitaria nuevamente.