Pruebas automatizadas de videojuegos: combina comprobaciones headless con evidencia de renderizado

Elige la evidencia que necesitas

Una build de un juego puede iniciarse sin problemas y, aun así, perder el inventario en una migración de partidas guardadas o renderizar mal un personaje por culpa de un shader. Define qué fallo debe detectar cada prueba. Usa comprobaciones específicas para las reglas del juego, pruebas de integración para los sistemas que interactúan entre sí y pruebas de renderizado para el comportamiento visual. El framework de automatización de Unreal distingue entre pruebas unitarias, de funcionalidad, de estrés de contenido y de capturas de pantalla. [2] Que una categoría pase no demuestra que las demás estén cubiertas.

Haz observable la ejecución desatendida

La interfaz de línea de comandos de Godot permite la ejecución headless, la ejecución de scripts del proyecto y una operación de importación que espera a que terminen las importaciones de recursos antes de cerrarse. [1] Un proyecto puede usar estas piezas para construir un runner de pruebas desatendido. Haz que ese runner devuelva un código de salida de error cuando falle una aserción y que conserve un informe estructurado.

Durante la configuración, verifica el camino de fallo con un fixture que falle a propósito. De lo contrario, un job puede parecer correcto simplemente porque lanzó un proyecto vacío, ignoró una opción no compatible o nunca ejecutó las comprobaciones previstas. Que la ejecución headless tenga éxito no prueba que la GPU de destino produzca los píxeles correctos.

Un ejemplo con una suite pequeña

Para un juego de acción ilustrativo, elige 20 pruebas de reglas específicas, cuatro comprobaciones de escena y tres fixtures de renderizado. Las pruebas de reglas pueden cubrir la capacidad del inventario y los requisitos para recibir daño. Las comprobaciones de escena pueden ejercitar la aparición de entidades, la restauración de un checkpoint, la transición de una puerta y una desconexión controlada. Los fixtures de renderizado pueden incluir una superficie con normal map, partículas transparentes y un límite de iluminación entre zona oscura y zona clara.

Reinicia cada fixture de forma independiente. Registra las semillas, los ticks de simulación, las versiones de los assets y las entradas relevantes. Volver a reproducir una grabación ayuda a recrear los fallos, pero una semilla fija por sí sola no garantiza una simulación idéntica entre plataformas. Estas cifras describen una suite propuesta, no pruebas realizadas en un juego real.

Controla las comparaciones de capturas de pantalla

Fija la cámara, la resolución, el renderer, la exposición y el punto de captura. Usa un job con GPU para la configuración de renderizado que quieras probar. La herramienta de capturas de pantalla de Epic ofrece tolerancias por canal y límites de error tanto locales como globales, ya que parte del renderizado produce variaciones. [3]

Conserva juntas la imagen baseline, la imagen nueva y la imagen de diferencias. Un error global pequeño puede ocultar un defecto local muy visible, como un ojo o un icono de la interfaz que falta. Elige los umbrales en función del fallo que quieres detectar y revisa los cambios de baseline como cambios de contenido. Reemplazar automáticamente todas las baselines que fallan eliminaría la evidencia de la prueba.

Mantén la suite útil

Ejecuta con frecuencia las comprobaciones rápidas y estables, y reserva los barridos costosos de plataformas o de contenido para una programación adecuada. Aísla los archivos generados y no des por hecho que otra prueba dejó el mundo en un estado útil. [2] En los informes, separa los fallos de infraestructura de las aserciones del juego que fallan.

Investiga las pruebas inestables en lugar de aumentar todos los timeouts o todas las tolerancias de imagen. Conserva la escena y la secuencia de entradas más pequeñas que expliquen un fallo. La automatización permite verificar de forma repetible; el playtesting sigue aportando evidencia sobre la sensación de juego, la legibilidad y las situaciones que la suite nunca llegó a codificar.

Fuentes

[1] Godot command line tutorial — Godot Engine contributors.

[2] Automation Test Framework — Epic Games.

[3] Screenshot Comparison Tool — Epic Games.