Estrategia de prueba para juegos

13

He heredado un juego educativo basado en la web. Durante el año pasado, trabajé para estabilizar el código y agregar nuevas funciones. La mayor parte de la lógica está en el extremo frontal, por lo que las pruebas unitarias de back-end, aunque son útiles, cubren un pequeño porcentaje del código.

El juego ha llegado al punto en que comienza a complicarse. Hay dos modos diferentes para cada juego y el juego se comporta de manera diferente según el modo. También hay varias banderas que afectan el juego.

He sido un desarrollador de aplicaciones por más de 10 años y esto me deja perplejo. En el mundo empresarial, un algoritmo siempre funciona de la misma manera. Escribiré una prueba de unidad para un algoritmo, esperaré el valor 42 y se producirá un error si no obtengo ese valor.

Cuando se trata de juegos, estoy perdido. ¿Cómo los pruebo? Tengo probadores disponibles para mí. Puedo dedicar tiempo a escribir pruebas unitarias.

Los probadores son ... no confiables. No son los mejores para eliminar problemas y no les he dado la mejor dirección. Aparte de gastar una tonelada de tiempo en cada ciclo de lanzamiento probando cada permutación y combinación del juego, ¿cómo debo usarlas como recurso?

Las pruebas unitarias parecen limitadas. Dado que la mayor parte de la lógica es javascript (y heredé el código spaghetti), puedo usar un paquete de aplicaciones para usuario como Cucumber o Selenium para garantizar que ciertas funciones funcionen.

¿Es esa la mejor estrategia? ¿Cómo prueban los juegos las compañías de juegos?

He leído la pregunta " Desarrollo guiado por pruebas para juegos complejos "(entre otros en el sitio), pero no aborda lo que estoy buscando. Estoy pidiendo estrategias, no ejemplos específicos de cómo realizar pruebas.

    
pregunta jeffkolez 08.09.2014 - 17:49

1 respuesta

16
  

En el mundo empresarial, un algoritmo siempre funciona de la misma manera. Escribiré una prueba de unidad para un algoritmo, esperaré el valor 42 y se producirá un error si no obtengo ese valor.

Esto no es muy diferente en los juegos. La presencia de dos modos y múltiples banderas en el juego en el que estás trabajando no cambia nada: si tomas un modo específico con un conjunto específico de banderas, obtendrás el mismo valor una y otra vez al probar una parte de el código fuente.

Con demasiados modos y banderas, el juego puede ser muy difícil de probar rápidamente, debido a la cantidad de variantes posibles. Para mitigar el riesgo de encontrarse con esta dificultad antes, debe:

  • Mock / stub severamente . Mantenga las partes probadas pequeñas y simule todo lo que confían.

    Si dependen del tiempo, simule que el objeto de tiempo siempre dé un resultado específico o un conjunto de resultados específicos, independientemente del tiempo real.

    Si confían en random() , simúllalo para proporcionar una constante cada vez.

  • Refactor . Si las pruebas comienzan a ser demasiado complicadas o si ve que una clase, para ser examinadas, requiere doce argumentos después de que implementó la inyección de dependencia, mientras que antes solo necesitaba dos, debe refactorizar el código.

  • Cuestione las reglas comerciales reales de la aplicación. Dejé de contar el número de proyectos que eran casi imposibles de probar debido a la cantidad de variaciones diferentes requeridas por los requisitos funcionales que nadie necesitaba ni entendía, ni siquiera los interesados.

    Cuando un pequeño sitio web de comercio electrónico necesita diez páginas para explicar los requisitos funcionales utilizados para determinar cómo se calculan los precios de envío, uno no debe comenzar escribiendo pruebas o código, sino que debe volver a los interesados y trabajar con ellos. para producir sane requisitos.

Finalmente, automatice todas las pruebas . Se necesitan probadores para descubrir situaciones en las que falla la aplicación. El uso de probadores para ejecutar, una y otra vez, la misma acción en cada revisión es contraproducente e irrespetuosa para los probadores: las pruebas de regresión deben ser realizadas por máquinas, no por personas. Las personas, por otro lado, son mucho mejores para encontrar posibles errores. "Qué pasa si yo ..." es una de las técnicas que pueden usar ("¿Qué sucede si ingreso unos megabytes de datos binarios que contienen varios \ x00 en un campo que pregunta por mi edad y veo qué ocurrirá?"), pero también se pueden utilizar enfoques más formales.

    
respondido por el Arseni Mourzenko 08.09.2014 - 19:37

Lea otras preguntas en las etiquetas