unitario unitarias software pruebas niveles las funcionales ejemplo desventajas testing mocking

testing - software - pruebas unitarias php



¿Cómo pueden las burlas de los servicios externos mejorar las pruebas unitarias? (3)

Me estoy conectando a un servicio externo simple, aunque idiosincrático.

Creo que las pruebas de mi unidad no deben depender de la disponibilidad o implementación de ese servicio externo, por lo que pretendo simularlo.

Necesito el simulacro para aceptar y devolver mensajes y respuestas realistas; de lo contrario, mis pruebas no representarán situaciones reales. Por ejemplo, tiene que arrojar el tipo correcto de errores, y hay al menos 7 formas diferentes en que puede fallar (entre usted y yo no es un servicio externo muy bien diseñado). Por lo tanto, como mínimo, tengo que tener un hash de pares mensaje / respuesta.

Entonces, en lugar de reducir la contingencia, la burla la ha reintroducido en otro lugar. De hecho, como dice el refrán, ahora tengo dos problemas: tengo que estar seguro de que lo que está en mi hash es una representación justa de cómo se comporta el servicio externo. Pero seguramente la fuente canónica de lo que el objeto de respuesta X da al mensaje m es X mismo. Cualquier otra cosa es arriesgada y desordenada.

¿He tomado un giro equivocado? ¿Cómo puedo eliminar esta aparente circularidad?

EDITAR : He aclarado cuál es el problema a la luz de los útiles comentarios de Justice.


Asegúrese de que cualquier cosa de la que su clase dependa tenga una interfaz (a diferencia de una implementación concreta), y luego puede usar JMock . Esto simplificará sus pruebas inmensamente. Puede hacer cosas como decirle que espere un método llamar a X, devolver un valor particular o lanzar una excepción. Es realmente un ahorro de tiempo.


Su simulacro para pruebas unitarias no debe representar con precisión el servicio externo. Debe elegir conjuntos predefinidos de valores de entrada y salida para el servicio externo burlado. Pueden o no ser lo que el servicio externo realmente devolvería (pero deberían ser "algo así como" reales). El objetivo de las pruebas de su unidad es verificar que sus objetos se comporten correctamente, dado este conjunto de entradas y salidas, para un cierto significado de "correctamente".


Permítanme referirme a mis dos respuestas en otra pregunta sobre pruebas unitarias solo para evitar repetirme a mí mismo, primero.

Lo que creo que la burla te da en este entorno es que especifica rigurosamente lo que crees que será el comportamiento de esa interfaz externa. Esto significa que tiene una prueba controlada (algo me dice que este servicio externo cambia cada cierto tiempo). Por lo tanto, no solo puede probar y depurar su código con una conocida "buena" secuencia de respuestas, sino que tiene un conjunto documentado de ejemplos de lo que espera

Si estuviera en esa situación, y dependiendo del servicio real, estaría tentado de escribir una prueba unitaria o simular también el servicio externo . De esta forma, si observa una falla en la operación real, puede (1) ejecutar la prueba contra su código utilizando el simulacro de la interfaz externa, y (2) probar el servicio externo contra sus expectativas.

El punto, sin embargo, es tener algo para lo que tenga una confianza real y que controle completamente.