Unidad de prueba de un proyecto de juego C # / XNA

He estado incursionando en el desarrollo de juegos desde que comencé a programar, pero nunca muy en serio. Trabajo como desarrollador de aplicaciones de negocios, pero estoy trabajando en algunos juegos en mi tiempo libre.

En el mundo de los negocios (en la pila de desarrollo web de Microsft), ASP.NET MVC se está volviendo muy popular, debido a su facilidad para probar la forma en que funciona la interfaz.

Me pregunto qué patrones de diseño (MVC, MVP, MVVM, etc.) se podrían usar para escribir un juego en el que toda la lógica del juego sea fácilmente comprobable por unidad. ¿Es esto posible o factible? ¿Estoy perdiendo el tiempo? ¿Es mejor hacer compilaciones completas y luego ejecutar pruebas de tipo "integración" en lugar de pruebas unitarias?

El código de muestra sería genial, pero una escritura también es útil.

(Intenté agregar una etiqueta de prueba de unidad, pero no tengo el representante requerido ...)

— Nate
fuente

Aquí hay un buen artículo que encontré que describe una arquitectura para separar la funcionalidad para que no solo sea fácilmente reutilizable, sino que también sea mucho más fácil de probar por unidad:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Algunos juegos se beneficiarán de un patrón similar a MVC. Me vienen a la mente juegos de mesa como el ajedrez y los juegos de cartas. En la mayoría de los casos, sin embargo, esto es una exageración masiva.

Personalmente, creo que es suficiente probar solo cosas unitarias que son de naturaleza algorítmica. Cosas de las que dependerás para "simplemente trabajar" cuando escribas código de juego, y pueden ser insidiosamente difíciles de rastrear problemas, si no lo hacen. Cosas como pruebas de intersección o código de red.

(¡Cosas que idealmente se integrarán en un marco de terceros para que no tenga que escribirlas o probarlas!)

Una técnica que me gusta usar para las pruebas unitarias relacionadas con el juego es lo que llamo la "prueba de la unidad visual". El concepto básico es una representación de línea simple del bit de código en cuestión (por ejemplo, una función de intersección), y algunas asignaciones básicas de teclas o mouse para manipular las entradas. Nadie dijo que las pruebas unitarias tienen que ser automatizadas, solo tienen que dividir las cosas en unidades individuales y probarlas.

— Andrew Russell
fuente

Buena respuesta. También quería publicar exactamente ese artículo. Los sistemas de componentes de Game Object son una excelente manera de separar la lógica y poder probarlos individualmente. Sin embargo, lo que ninguna prueba unitaria puede hacer son las complejas interacciones de múltiples caminos de lógica de juego que interactúan en tiempo real en secuencia aleatoria. Eso sería como tratar de probar la unidad del pronóstico del tiempo. :)

— LearnCocos2D

Sí, también hago pequeños probadores que aíslan bits particulares de funcionalidad. Me aseguro de cualquier cambio que realice en las API, etc. Siempre me aseguro de que todavía funcionen. Mucho más fácil reutilizar la funcionalidad en su próximo proyecto.

— Iain

Sí, buena respuesta, y me gusta el enlace. Y estuve de acuerdo con todo hasta la última línea, "Nadie dijo que las pruebas unitarias tienen que ser automatizadas". :) Tengo que hacerlo, tal vez no, pero todo lo que he leído implica (o dice directamente) que las pruebas unitarias deben automatizarse , hasta el punto de que solo presione un solo botón para ejecutar todas sus pruebas. De lo contrario, cuanto más trabajo implique la ejecución de las pruebas, es menos probable que las ejecute con la frecuencia suficiente. De acuerdo, si está hablando del código de visualización , puede ser mucho más difícil hacer una prueba unitaria, si es posible.

— Cyclops

Casi cuatro años después, y siento que he desarrollado una mejor comprensión de por qué la "prueba de unidad visual" funciona tan bien: las pruebas de unidad son una herramienta de desarrollo. Una prueba unitaria automatizada típica puede decirle que algo está roto. Pero una prueba de unidad visual puede permitirle explorar algoritmos muy complicados y ayudarlo a identificar rápidamente por qué algo está roto (particularmente cuando se combina con la edición de código en vivo). A menudo, una prueba visual puede identificar problemas que de otro modo tendría que anticipar para probar con el código, o problemas donde no hay una respuesta "correcta" (por ejemplo: ajuste).

— Andrew Russell

Y la idea de que las pruebas unitarias deben ejecutarse "con la suficiente frecuencia" (como en: siempre, de forma automatizada) es falsa. Obviamente, el código que no cambia no necesita volver a probarse. Y cuando el código se está modificando, el desarrollador que realiza las modificaciones debería hacerlo mientras utiliza las pruebas disponibles apropiadas (visuales, basadas en código o de otra manera). Obviamente, existe un código con un cierto perfil de riesgo donde una prueba automatizada es una inversión de tiempo que vale la pena. Pero tales escenarios son especialmente raros en el desarrollo de juegos.

— Andrew Russell