Prueba de estrategia para juegos

Heredé un juego educativo basado en la web. Durante el año pasado trabajé para estabilizar el código y agregar nuevas características. La mayor parte de la lógica está en el front-end, por lo que las pruebas unitarias de back-end, aunque ú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 desarrollador de aplicaciones durante 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 unitaria para un algoritmo, esperaré el valor 42 y 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 pasar tiempo escribiendo pruebas unitarias.

Los probadores son ... poco confiables. No son los mejores para solucionar los problemas y no les he dado la mejor dirección. A menos que gaste una tonelada de tiempo en cada ciclo de lanzamiento probando cada permutación y combinación del juego, ¿cómo debo usarlos 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 una suite de aplicaciones para usuario como Cucumber o selenium para asegurar 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 impulsado 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 evaluar.

En el mundo empresarial, un algoritmo siempre funciona de la misma manera. Escribiré una prueba unitaria para un algoritmo, esperaré el valor 42 y 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, aún 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 volverse muy difícil de probar rápidamente, debido a la cantidad de posibles variantes. Para mitigar el riesgo de encontrarse con esta dificultad temprano, debe:

• Mock / stub severamente . Mantenga las piezas probadas pequeñas y burlarse de todo lo que dependen.

  Si confían en el tiempo, imite el objeto de tiempo para dar siempre un resultado específico o un conjunto de resultados específicos, independientemente del tiempo real.

  Si confían en él random(), búrlate para proporcionar una constante cada vez.

• Refactor . Si las pruebas comienzan a ser demasiado complicadas o si ve que una clase, para ser probada, requiere doce argumentos después de implementar la Inyección de dependencias, aunque solo requirió dos antes, necesita refactorizar el código.

• Cuestione las reglas comerciales reales de la aplicación. Dejé de contar la cantidad 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 las partes interesadas.

  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ódigos, sino que debe comunicarse con los interesados ​​y trabajar con ellos para producir requisitos sanos .

Finalmente, automatice cada prueba . Se necesitan probadores para descubrir situaciones en las que la aplicación falla. Usar probadores para ejecutar, una y otra vez, la misma acción en cada revisión es contraproducente e irrespetuoso con 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é pasa si ingreso algunos megabytes de datos binarios que contienen varios \ x00 en un campo que pregunta por mi edad y veo qué pasará?"), pero también se pueden usar enfoques más formales.