¿Qué tan común son las pruebas automatizadas en el desarrollo de juegos? [cerrado]

¿Los desarrolladores de videojuegos usan para escribir pruebas unitarias y de integración? ¿Qué tan común es entre los desarrolladores de rompecabezas? ¿Y entre los desarrolladores de MMORPG y FPS?

(No tengo experiencia en el desarrollo de juegos ni estoy pensando en trabajar con él, es solo una duda que se me ocurrió. Por lo tanto, no necesito tratar de convencerme de que los escriba, incluso porque ya me gusta escribir pruebas automatizadas. )

En general, las pruebas unitarias y de integración de juegos no son tan comunes. Esto se debe principalmente a que el aspecto de representación de los juegos generalmente está estrechamente relacionado con el resto de la mecánica del juego, por lo que puede ser muy difícil escribir pruebas unitarias que funcionen.

Dicho esto, las pruebas unitarias pueden ocurrir en el desarrollo del juego, y si el código está configurado para ello, puede ser de gran beneficio. Sin embargo, puede ser mucho más común escribir pruebas automatizadas para juegos, generalmente en forma de un programa de inteligencia artificial que puede jugar el juego de manera efectiva a una velocidad mayor que un jugador normal. Hay algunas historias excelentes de desarrolladores que hacen exactamente eso en esta pregunta sobre pruebas automatizadas . Este tipo de pruebas automatizadas es potencialmente mejor, ya que las pruebas unitarias pueden no detectar un error en el motor de renderizado, pero es más probable que una prueba automatizada exponga dicho problema.

Al final, sin embargo, todo esto depende del estudio. Algunos estudios realizarán algún tipo de prueba automatizada, mientras que otros podrían contratar a 20 niños de secundaria durante el verano para jugar durante horas.

En mi experiencia, no es muy común.

La mayoría de las pruebas unitarias no ocurren porque la mayoría de los desarrolladores de juegos provienen de una época y una cultura anteriores a cosas como esa, y por lo tanto, es difícil argumentar ahora que tales métodos son necesarios. Esto se ha vuelto aún más cierto en los últimos años con la expectativa de que el usuario pueda parchear su propio software después del lanzamiento.

En parte se debe a que el lenguaje dominante en la industria del desarrollo de juegos es C ++ y eso hace que las pruebas unitarias sean un poco más engorrosas que otros lenguajes. Existen marcos de pruebas unitarias, pero no son tan fáciles de usar como sistemas similares en lenguajes más modernos que pueden usar la reflexión y trucos similares para acelerar la detección de casos de prueba.

Además, es porque los juegos generalmente no se prestan a pruebas unitarias: gran parte de la lógica depende de fuentes semi-deterministas (por ejemplo, hardware de gráficos, tiempos de entrada, velocidad de cuadros), gran parte de la salida es difícil de medir (por ejemplo. gráficos en pantalla, efectos de sonido) y algunos carecen de sentido fuera del contexto completo del juego (por ejemplo, IA reactiva compleja, simulaciones físicas). Hay excepciones, muchas, si trabajas duro para hacer el código de esa manera, pero en general las pruebas son más caras en los juegos que en la mayoría de los otros tipos de software, por lo que la relación costo / beneficio es más dudosa.

En cuanto a las pruebas de integración, nunca he oído hablar del término que se usa explícitamente en el desarrollo de juegos, pero muchos desarrolladores realizan pruebas automatizadas de todo el sistema siempre que sea posible. Supongo que tal vez 1 de cada 3 desarrolladores profesionales hacen esto, ya que no siempre es fácil de configurar, y porque los beneficios se reducen por el hecho de que casi todos los desarrolladores medianos a grandes (o su editor) tienen un control de calidad departamento que realizará manualmente pruebas similares. El control de calidad generalmente se paga mucho menos que los desarrolladores, por lo que puede considerarse económico dejar las pruebas a ellos, en lugar de invertir tiempo adicional en el código. (Polémico.)

No veo cómo escribir un juego es diferente a cualquier otra pieza de software en lo que respecta a las pruebas. Cada componente del software, ya sea que esté activando un evento cronometrado, enviando comandos a un personaje dentro del juego o presionando los botones del menú, debe probarse para su correcta ejecución.

Probar si es posible completar el juego es una cuestión diferente y no se incluye tanto en las pruebas unitarias o de integración.

En general, la automatización de las pruebas de IU (incluso en programas regulares) es más difícil que la automatización regular. Entonces, aunque puede escribir pruebas unitarias para sus juegos, probar el juego real es más difícil. La mayoría de las empresas utilizan probadores humanos que ejecutan el juego una y otra vez.

Por ejemplo, aquí hay un artículo que explica cómo lo hacen en un pequeño Game Studio (2 desarrolladores). Por lo que leí, parece que su validación no es muy detallada (la automatización inicia el juego y registra los errores / afirmaciones).

Sin embargo, algunas empresas tienen mucho éxito con la semi automatización (como Microsoft Test Studios). Es decir, los desarrolladores o las SDET crean herramientas que hacen que probar el juego sea mucho más fácil. Ha habido charlas en Gamefest donde discuten cómo probaron Crackdown, por ejemplo, o Fable. Por ejemplo, todavía usan probadores que verifican que cada objeto está donde se supone que debe estar, pero usan una herramienta que toma una instantánea de esa ubicación para que todo lo que el humano hace es verificar visualmente que está allí sin tener que jugar el juego.

Aquí hay una buena charla sobre qué tipo de herramientas construyen / usan para probar los juegos. Se llama "Test Lead Gems: salir frente a la creciente complejidad de nuestros juegos"

Sin embargo, apostaría a que el código de servidor MMO y multijugador se prueba un poco más a menudo.

Por lo menos, las pruebas de regresión automatizadas han sido comunes. He visto estos implementados como controles de cordura masiva durante el inicio del servidor, por ejemplo, para asegurarme de que un nuevo servidor "en la nube" se haya configurado correctamente antes de que comience a aceptar jugadores; un conjunto de regresión bastante bueno creado durante 3-4 años, en ese caso, se ejecutó en aproximadamente 4 segundos, mientras que abrir un host virtual (desde una imagen de SO en blanco) tomó casi 10 minutos, por lo que valió la pena el tiempo. Ejecutamos las mismas pruebas en un "tinderbox" (sistema de compilación continua) en nuestro repositorio de Subversion para verificar algunos errores molestos y bastante comunes a los que les gustaba volver. En particular, la funcionalidad de varios servidores tenía la desagradable costumbre de intentar crear duplicados de objetos a medida que se pasaban: la instanciación de objetos, el almacenamiento en caché, y el código de paso de red estaba cerca del 100% cubierto; seguimos pensando que habíamos pensado en todo lo que podría probarse, y luego descubrimos algunos casos divertidos y novedosos.

En varios MMO en los que he trabajado, también desarrollamos "clientes auxiliares" para realizar pruebas unitarias iniciales, y generalmente proporcionamos comandos de "operador" para realizar pruebas unitarias ad-hoc de nuevas características. Esto nos permite ejecutar el código del servidor antes de que el cliente esté listo para aprovecharlo y ejercer situaciones "imposibles" (por ejemplo, teletransportar a un jugador dentro de una pared) para garantizar que los controladores de recuperación de errores funcionen bien. Poner en línea una nueva característica en el servidor a veces puede llevar muchos días menos que el soporte del cliente; por el contrario, a veces tendríamos que crear un método de servidor "ficticio" para el cliente, devolviendo datos falsos pero bien formados, si se adelantan a nosotros.

Sin embargo, el desarrollo de MMO en general está sujeto a muchos más problemas de este tipo, que podrían reflejar el medio ambiente. Cuando estaba trabajando en sistemas de juegos integrados, la "prueba" era prácticamente desconocida para cualquier cosa, excepto algún código de widget reutilizable (por ejemplo, editores de texto).

Otra razón por la cual las pruebas automatizadas no son tan comunes en el desarrollo de juegos que se pueden considerar es que para la mayoría de los juegos hay muchos voluntarios de pruebas Beta que prevén la participación de Game Beta como una "ventaja" cuando se lanza el juego. Por supuesto, las pruebas automatizadas han surgido de los requisitos de calidad, pero también de las restricciones presupuestarias. Por lo tanto, dado que en los juegos hay muchos probadores experimentados que están preparados para realizar pruebas de forma gratuita, quizás esta sea otra razón por la cual las pruebas automatizadas no están tan extendidas.

Participé en una mesa redonda sobre pruebas automatizadas en GDC 2011 . IIRC, había alrededor de 60 personas en la sala. En un momento, el moderador realizó una encuesta sobre la cobertura de las pruebas unitarias. Hubo una persona que reclamó una cobertura de código superior al 90%. Todos los demás se rieron ante la idea de alcanzar el 1% de cobertura. Si ese grupo es una representación justa de la industria en su conjunto, diría que las pruebas automatizadas generalmente no ocurren mucho, si es que lo hacen.

Las otras respuestas aquí dan buenas razones de por qué. Solo pensé que sería útil tener una cuenta de primera mano.