Más de 1000 pruebas para un juego hecho por hobby: ¿un derroche?

Nuestro proyecto ya tiene bastante más de mil pruebas automatizadas: unas 990 en el lado del servidor y unas 120 en el cliente de Unity. Para un proyecto familiar, suena exagerado. Es justo lo contrario, y aquí va el porqué.

Las pruebas son nuestro segundo desarrollador. En un proyecto en solitario no hay nadie que diga en la revisión de código: «Espera, eso rompe la fabricación». Las pruebas son ese compañero. Cada mecánica de juego (recetas, oxígeno, hambre, comportamiento de las criaturas, contraseñas de los mundos) tiene pruebas que se ejecutan con cada cambio. Poder refactorizar sin miedo es la verdadera ganancia.

Lo bastante rápidas para no molestar. Las pruebas que tardan un cuarto de hora no las ejecuta nadie. Por eso nuestro filtro de CI tiene dos etapas: la comprobación de cada pull request tarda poco más de tres minutos con las pruebas rápidas, y la batería completa y lenta se ejecuta después. Así el ciclo de desarrollo sigue siendo ágil sin perder cobertura.

Probar Unity es todo un tema aparte. La lógica del cliente es difícil de probar dentro de un motor en marcha. Nuestro truco: la lógica central del cliente vive en su propia biblioteca, que funciona sin Unity, y la probamos sin interfaz gráfica (headless), como código normal. Solo lo que de verdad necesita el motor se ejecuta como prueba de EditMode/PlayMode.

Las advertencias son errores. Nuestra CI compila con «warnaserror»: cualquier advertencia del compilador rompe la build. Suena pedante, pero evita el cementerio de advertencias en el que, tarde o temprano, se ahoga la única advertencia importante.

El balance honesto: escribir pruebas cuesta quizá una quinta parte del tiempo de desarrollo. Pero cada función arreglada sigue arreglada, y para un proyecto que cobra vida por las noches después del trabajo, nada vale más que la certeza de que la función del fin de semana no rompió la del martes.