unit-testing - tipos - tdd
Pruebas unitarias de un método con comportamiento aleatorio. (6)
Estoy escribiendo casos de prueba de unidad para un juego en el que estoy trabajando. Cuando el juego comienza, el jugador se posiciona al azar, y tengo dos problemas con eso:
- Dado que el jugador está posicionado al azar, no puedo estar seguro de que un caso de prueba que pase una vez pase nuevamente. Por ejemplo, podría pasar la mayor parte del tiempo, pero fallar si el jugador está colocado frente a un obstáculo.
- Tengo que probar todas las situaciones en un caso de prueba. Por ejemplo, al probar si el jugador se mueve correctamente, tengo que verificar si hubo un obstáculo y si fue considerado por el algoritmo.
No estoy realmente feliz con eso, pero no veo una salida. ¿Es aceptable probar métodos con comportamiento parcialmente aleatorio?
Como han dicho otras respuestas, los algoritmos aleatorios son deterministas. Puedes reproducir una secuencia si usas la misma semilla.
Las únicas situaciones en las que tuve que lidiar con un código no determinista es cuando se trataba de multihilo. Entonces, usted depende del programador del sistema operativo.
En esos casos, escribo la prueba de unidad como un bucle, que repite miles de veces el código de prueba.
Convierta la fuente de aleatoriedad en una entrada para la prueba y configúrela para que sea la misma cada vez.
Casi todos los generadores de números aleatorios toman un valor ''semilla''. Al proporcionar el mismo valor de semilla cada vez, puede saber que obtendrá la misma secuencia de números aleatorios y, por lo tanto, la salida de su aplicación debe ser exactamente la misma.
Tengo que probar todas las situaciones en un caso de prueba.
¿Por qué? Puede tener múltiples casos de prueba. Puede seleccionar cualquier número de semillas de números aleatorios diferentes y arbitrarias para crear las condiciones que desea probar. O simplemente reemplace el posicionamiento aleatorio con un posicionamiento específico para los propósitos de la prueba.
De acuerdo con la teoría de las pruebas, no es posible probar el comportamiento aleatorio :) Por otro lado, como se dijo en las respuestas anteriores, para las pruebas se podrían realizar actividades pseudoaleatorias de alguna manera.
Hay dos cosas diferentes para probar aquí, y usted debería probarlas por separado:
- ¿Funciona la lógica del programa para todas las posiciones iniciales posibles? Prueba esto colocando al jugador de forma no aleatoria en una serie de posiciones, tratando de cubrir todos los "casos especiales".
- ¿Es el posicionamiento aleatorio realmente aleatorio? Pruebe esto llamando solo a la lógica de posicionamiento muchas veces y realice algún tipo de análisis estadístico.
Le sugiero que trate su fuente de aleatoriedad (un generador de números aleatorios o lo que sea) como una dependencia. Luego puede probarlo con entradas conocidas proporcionando un RNG falso o uno con una semilla conocida. Eso elimina la aleatoriedad de la prueba y la mantiene en el código real.
Si falsifica el RNG, puede probar lo que sucede si, naturalmente, posicionaría al jugador en un obstáculo: cómo lo aleja, etc. Por supuesto, eso depende de saber cómo la clase usa el RNG, pero personalmente Estoy lo suficientemente contento con las pruebas unitarias que actúan como "pruebas de caja blanca" con algún conocimiento interno.
Un enfoque que puede tomar es dividir la generación de posiciones aleatorias en una clase / interfaz separada, de modo que pueda anularla en su prueba y, por lo tanto, controlarla.