unit testing - tipos - ¿Las pruebas unitarias son viables en la programación de juegos?

tipos de pruebas de software

Question

Me gusta la idea de la prueba unitaria, pero tengo problemas para aplicarla a la programación de juegos. Los juegos son muy explícitos y, a menudo, el código no se divide en unidades distintas. En mi experiencia, la mayoría de las funciones mutan el estado en lugar de devolver los valores.

Considere una acción simple como playerJump(height) . Me encantaría tener un banco de pruebas que verifique una gran variedad de casos para asegurarse de que saltar salga siempre como se espera. Sin embargo, esta función probablemente no devuelva ningún valor y tenga el efecto secundario de, player.velocity.y = -height y checkCollisions(player) . No puedo pensar en una prueba de unidad clara para construir alrededor de esto.

¿Las pruebas unitarias simplemente no son viables en aplicaciones de alto nivel de estado como los juegos? ¿Las ventajas de las pruebas unitarias son tan grandes que valdría la pena programar juegos funcionalmente?

Actualizar:

Games from Within tiene una serie de artículos detallados sobre el uso de Test Driven Development en los juegos. Los recomiendo a cualquier persona interesada en este tema. Aquí está el primer artículo:

http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1

Answer 1

A las pruebas unitarias simplemente no les importa qué tan "con estado" sea su unidad. Tiene una pieza de código más o menos autónoma, y ​​si su vector de entrada y salida es enorme, la prueba es difícil. Si estos vectores se establecen o no como estados antes y después de la ejecución no cambia un poco sobre la prueba. Sin embargo, si quiere decirnos que no puede pensar en una forma adecuada de definir casos de prueba como en la mayoría de los tutoriales / documentos de pruebas unitarias, es decir, el sujeto de prueba es algo así como "f (x) = y", entonces sí, estoy de acuerdo, tendrá dificultades para demostrar que los pocos (x [100], y [99]) vectores con los que se obtiene una caña humana arrojan suficiente cobertura (¡numéricos!). Intente formular propiedades integradoras e invariantes e ir a pruebas automatizadas.

Answer 2

Eche un vistazo a PEX para la generación automática de pruebas unitarias. Generará pruebas unitarias para todas las posibles variaciones de entrada, lo que te ayudará a probar muchas combinaciones posibles.

Answer 3

La programación es programación. Las pruebas unitarias son útiles para cualquier tipo de aplicación porque le ayudan a detectar y corregir errores (y, a menudo, lo más importante, las regresiones introducidas inadvertidamente al refactorizar el código) de forma inmediata y eficiente.

Por supuesto hay áreas de comportamiento de alto nivel que son difíciles de probar por unidad, pero eso no es realmente para lo que son las pruebas unitarias: son principalmente para verificar que los métodos individuales o partes pequeñas de la base de código hagan lo que se supone que deben hacer.

Para los comportamientos de nivel superior, debe aplicar otros enfoques de prueba (pruebas de regresión, por ejemplo: alimentar una secuencia fija de entradas en el juego y luego verificar que obtenga los mismos resultados cada vez, o generar vistas de la cámara en ubicaciones fijas a lo largo de un nivel y verificar que siempre generan la misma imagen (o al menos razonablemente similar))

Tu ejemplo de PlayerJump es uno de esos casos. Puede probar la unidad o la regresión aislándola con entradas constantes (coloque programáticamente el personaje del jugador en una ubicación fija en una escena de prueba simple y ejecute el evento de salto, luego verifique que las colisiones o el lugar de descanso final sean consistentes. biblioteca de diferentes objetos que el jugador puede saltar "en", puede cubrir una gran cantidad de casos de prueba (por ejemplo, que el salto tiene éxito sobre un espacio de la distancia de salto máximo prescrita).

Más allá de eso, sin embargo, los juegos requieren una gran cantidad de pruebas de juego (donde los usuarios reales simplemente lo juegan). Esto encontrará casos extraños que no cubrió con pruebas automáticas, pero lo más importante es que responderá a una pregunta que las pruebas automáticas nunca responderán: ¿se "siente" correctamente? Es divertido"? Estas son pruebas que solo un ser humano puede realizar.

Answer 4

Las pruebas unitarias pueden ser útiles para muchas de las bibliotecas de bajo nivel que puede usar con el código del juego, pero dudo seriamente que sea de mucha utilidad para las cosas de más alto nivel. Los juegos suelen ser simulaciones y se basan en cantidades masivas de estado compartido que no se pueden burlar ni probar de forma significativa de forma aislada. A menudo, las funciones en los juegos no devuelven ningún tipo de valor que pueda verificar al instante, sino que establece un proceso en movimiento que debe completarse en algún momento en el futuro. Probar tal comportamiento vale la pena, pero requiere un enfoque significativamente diferente a la idea de la prueba de unidad de probar piezas de código de forma aislada.

Answer 5

Mi experiencia con la unidad y las pruebas automáticas durante el desarrollo de Crysis 2 está disponible aquí: http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html Espero que ayude.

Resumen:

Las pruebas automatizadas mejoraron la estabilidad de los entregables, aumentando la productividad tanto para creadores de contenido como para ingenieros. Las pruebas automatizadas son una herramienta efectiva para mejorar la calidad del código y reducir las posibilidades de tener que trabajar horas extras. La industria del juego en su conjunto es muy reaccionaria. argumentos irracionales en contra No lo llame prueba, llámelo de otra manera, casi cualquier otra cosa (mire el desarrollo impulsado por el comportamiento) Sea flexible, escribir buenas pruebas es difícil y requiere habilidades que no están ampliamente disponibles en la industria del juego

Answer 6

Muchos programadores de juegos usan la arquitectura Entity-component-system . Lo hacen porque hace que sea más fácil modificar el comportamiento de los objetos del juego. Pero, como sucede, también hace que resulte más fácil probar tu código en una unidad.

Answer 7

A menudo, el código no se divide en unidades distintas.

Eso es solo diseño pobre. El código no se divide en nada. Usted, el diseñador, tiene que imponer una estructura en el código para que pueda demostrar que realmente funciona.

Sin embargo, esta función probablemente no devuelva ningún valor ...

¿Asi que?

... y tiene el efecto secundario de, player.velocity.y = -height y checkCollisions(player) .

Luego prueba eso.

No puedo pensar en una prueba de unidad clara para construir alrededor de esto.

Por qué no? Acabas de dar una excelente especificación para los resultados de la función.

Es posible que necesite algunos objetos falsos para reemplazar el reproductor completo con un MockPlayer simplificado que sea más fácil de probar.

Pero tu especificación de comportamiento fue perfecta. Solo prueba las cosas que describes.