Estoy escribiendo pruebas unitarias para un sistema de dirección para un videojuego. El sistema tiene varios comportamientos (evite esta área debido a la razón A, evite esta área debido a la razón B, cada una agregando un poco de contexto a un mapa de la región. Una función separada luego analiza el mapa y produce un movimiento deseado.
Estoy teniendo problemas para decidir cómo escribir las pruebas de unidad para los comportamientos. Como lo sugiere TDD, solo me interesa cómo los comportamientos afectan el movimiento deseado. Por ejemplo, evitar-por-la-razón-A debería resultar en un movimiento lejos de la posición incorrecta sugerida. No me importa en realidad cómo o por qué el comportamiento agrega contexto al mapa, solo que el movimiento deseado está lejos de la posición.
Así que mis pruebas para cada comportamiento configuran el comportamiento, lo hacen escribir en el mapa y luego ejecutan la función de análisis de mapa para calcular el movimiento deseado. Si ese movimiento satisface mis especificaciones, entonces estoy feliz.
Sin embargo, ahora mis pruebas dependen tanto de que los comportamientos funcionen correctamente como de que la función de análisis de mapas funcione correctamente. Si la función de análisis falla, obtendré cientos de pruebas fallidas en lugar de un par. Muchas guías de redacción de exámenes sugieren que esto es una mala idea.
Sin embargo, si pruebo directamente la salida de los comportamientos burlándome del mapa, entonces seguramente me estoy acoplando demasiado a la implementación. Si puedo obtener el mismo movimiento deseado del mapa utilizando un comportamiento ligeramente diferente, entonces las pruebas aún deberían pasar.
Así que ahora estoy sufriendo disonancia cognitiva. ¿Cuál es la mejor manera de estructurar estas pruebas?