Supongamos que tengo una función A que toma una cadena. La función A llama a la función B desde el mismo archivo, que toma esa cadena y la modifica. La función A luego devuelve un valor basado en la cadena de salida modificada de la función B.
¿Cómo debo escribir mejor las pruebas unitarias para la función A dado que depende de la salida de B? Si mi comprensión es correcta, las pruebas unitarias deberían probar la lógica de una función independientemente de sus dependencias. Siguiendo esta línea de pensamiento, estaba pensando en burlarme de la función B y su salida para que la prueba de A no fallara necesariamente si la función B no funcionaba. ¿Es correcta esta línea de pensamiento? Ejemplo de caso a continuación:
const functionA = (string, table) => { const hex = functionB(string); return table[hex]; } const functionB = (string) => { //some kind of hexing function here return hexed string }La respuesta habitual es simplemente escribir sus pruebas para A sin burlarse de B.
La explicación es que "probar una función independientemente de sus dependencias" no era en realidad una prioridad. Beck, Jeffries y otros utilizaron la ortografía "Prueba unitaria", pero no lo dijeron en el sentido habitual. Más tarde, probaron "prueba de desarrollador" y "prueba de programador" como etiquetas, pero para entonces se había instalado la costumbre y el daño ya estaba hecho.
Una forma de ver que esto debe ser cierto es considerar escribir pruebas para una "unidad" y luego realizar una refactorización que extraiga otro método: las pruebas originales aún funcionan, aunque el sujeto de prueba ya no sea una sola "unidad". ".
Hay, por supuesto, casos en los que querrá introducir una implementación sustituta para B al probar A
(Su preocupación parece ser la del medio).
Otro enfoque posible es extraer otra función de A
const functionA = (string, table) => { return functionC(string, table, functionB); } const functionB = (string) => { //some kind of hexing function here return hexed string } const functionC = (string, table, fn) { const hex = fn(string); return table[hex]; }Aquí, la función A es "tan simple que obviamente no hay deficiencias"; hemos trasladado todo el riesgo a functionC. El "stub" / "test-double" que queremos usar como sustituto de functionB es solo otro argumento.