¿Se utiliza BDD (Behavior Driven Development) en los juegos?

He estado leyendo sobre BDD - Behavior Driven Development durante un tiempo, y me resulta muy fácil y útil convertir funciones en código. Los usuarios de BDD a menudo lo llaman TDD bien hecho.

BDD es una herramienta para el diseño de software, desde afuera hacia adentro, desde el valor comercial (o valor de juego) hasta el código.

Dan North presentando BDD

¿Conoces algún recurso sobre BDD y juegos aparte de esto ?

Probablemente sea seguro decir que algunos desarrolladores de juegos usan BDD, como TDD, o (inserte aquí el paradigma de moda de moda del paradigma de moda), pero probablemente no saben que son ni necesariamente podrían identificar lo que realmente significa BDD. . La pregunta es realmente cuánto lo usan y cuánto tienen que usar para que te importe.

Por ejemplo, donde trabajo, todos nuestros nombres de pruebas unitarias son "oraciones" como Dan North sugiere en el artículo que vinculó. Eso por sí solo no es suficiente para decir que usamos BDD, por supuesto, pero ¿tal vez es lo que realmente te importa?

El enfoque, en mi opinión, no debería estar en qué palabra de moda aplicas en un estudio, sino en qué productividad y técnicas de proceso de desarrollo empleas en general. Me parece que los equipos más productivos están mezclando y combinando técnicas de una variedad de "paradigmas de palabras de moda" en lugar de comprometerse, dogmáticamente, con cada doctrina rígida que algunos estudios de Internet dicen que comprende un paradigma de palabras de moda en particular.

Lo veo más a menudo con la tendencia Agile: los equipos que se identifican a sí mismos como "haciendo Agile" tienden a ser más inflexibles (irónicamente) sobre el proceso que los equipos que incorporan orgánicamente los fragmentos de Agile que tienen sentido para ellos. Los antiguos equipos casi siempre terminan siendo menos productivos, en mi experiencia.

Un equipo de desarrollo está formado por humanos, que no son engranajes intercambiables en una máquina. Operan únicamente como individuos y como la combinación única de ellos mismos. La forma de un desarrollo efectivo no es doblar a sus humanos en el molde {BDD, Agile, whateverIsNext}, sino reevaluar constantemente la forma en que el equipo progresa y apuntalar las deficiencias en el proceso, reemplazar las tecnologías rotas y reforzar las cosas que son trabajando. En resumen, centrarse en enviar un título y no en "ser ágil (o lo que sea)".

¿Lo es? Tal vez. Mi opinión sería que sería un ajuste muy pobre para el software de entretenimiento en general, aunque podría funcionar bien para las bibliotecas de bajo nivel.

EDITAR: Aquí hay alguna justificación para mi opinión.

Wikipedia define BDD como una técnica que "fomenta la colaboración entre desarrolladores, control de calidad y participantes no técnicos o empresariales en un proyecto de software". Esto ya parece una mala idea porque los juegos difieren de la mayoría del software en que no están diseñados como herramientas para satisfacer una necesidad específica de un "participante no técnico o comercial", sino que son trabajos coherentes diseñados en general para entretener. Hay un énfasis en el "comportamiento de software deseado", pero los juegos rara vez tienen un "comportamiento de software deseado", excepto a nivel técnico. Definitivamente hay mérito en verificar esa parte del código, pero no con el usuario final, porque nunca lo verán.

Pero supongamos que desea deshacerse de las cosas de los interesados ​​humanos y simplemente usar BDD para hacer cumplir los contratos entre diferentes módulos de código, que, hasta donde puedo ver, no difiere mucho del desarrollo normal basado en pruebas, que también considero mal. adecuado para juegos, por la siguiente razón.

Las pruebas son útiles para verificar que eventos discretos ocurrieron cuando se esperaban. Esto funciona bien en la programación basada en eventos, es decir. La mayor parte del mundo del software, donde se realiza una acción, se genera una salida y luego simplemente verifica que la acción y el resultado coincidan. Sin embargo, el software del juego suele ser una simulación, donde una acción no tiene un resultado discreto sino un cambio continuo en el estado mundial. Si mi jugador oculto hace un ruido, me gustaría comprobar que la IA me persiga. Por lo tanto, puedo crear una prueba para asegurarme de que la IA esté en estado de 'caza' después de crear un ruido, y eso es genial. Pero, ¿cómo sé que la caza incluso funciona? No puede verificar eso instantáneamente, solo puede observarlo a lo largo del tiempo.

Además, un enfoque de prueba primero puede crear una falsa sensación de seguridad y hacer que las personas crean que el código es mejor de lo que realmente es.

def check_dice_roll_in_range():
    d = new Dice()
    assert(d.roll() between 1 and 6)

class Dice:
    def roll():
        return 4

Dado que el resultado de una prueba puede dar un falso positivo, nunca puede escapar de la necesidad básica de verificar el código en sí. Pero si el código en sí se verifica adecuadamente, la prueba adquiere una importancia secundaria. Por eso, en mi opinión, las pruebas se utilizan mejor después del evento, para probar las correcciones de errores.

No diría que nunca hay ningún beneficio en probar que, cuando los objetos X e Y funcionan juntos, el resultado que obtienes es el esperado. El problema es si está utilizando la forma más efectiva de verificar esto. Los métodos podrían incluir la verificación formal, una revisión del código, los métodos de prueba primero, los métodos de última prueba, la prueba tradicional de caja negra de control de calidad, o simplemente usar el código como se esperaba y observar los resultados. Las dos últimas opciones son sorprendentemente efectivas la mayor parte del tiempo, porque a pesar de parecer que carecen de rigor, la mayoría de los errores se encuentran durante el uso típico, y comprender un error en su contexto natural a veces puede ser más fácil que comprenderlo en una prueba artificial aprovechar. En la parte superior de esta,

Entonces, en resumen, creo que el desarrollo impulsado por pruebas no es necesariamente una gran opción para el software, que las pruebas por sí solas nunca son suficientes para garantizar la calidad del software (y, por lo tanto, el tiempo dedicado a escribirlas debe compararse con los usos alternativos de ese tiempo de desarrollador), que los juegos son una combinación especialmente pobre para los casos de prueba automatizados, y que los juegos son una combinación especialmente pobre para los métodos de desarrollo que buscan enfatizar el "valor comercial" y las "pruebas de aceptación".

(Espero que sea una mejor respuesta, incluso si no está de acuerdo con mis puntos).

Creo que BDD es apropiado en todos los entornos. Como otros mencionaron, está desarrollando software y, como resultado, debe probarlo. Me gusta bdd para algunas de las semánticas aleatorias mencionadas como nombres de prueba como oraciones. También me gusta agrupar ciertas pruebas juntas mientras puedo probar 1 clase.

Para combatir otros mensajes aquí, me gustaría señalar que en un proyecto más grande es MUCHO más difícil refactorizar el código sin pruebas. Si refactoriza algún código, está volando a ciegas en cuanto a si todo explotará en un resplandor de gloria o no. Las pruebas te ayudan a detectar cosas temprano. Entonces escribe su prueba, falla, codifica lo suficiente para pasar y continuar. Cuando refactorice debe hacer lo mismo, pero en lugar de escribir revisa la prueba. En la mayoría de los casos, si ejecuta la prueba, fallará, cambiará lo que cree que debería cambiar y TODAVÍA falla. En ese momento, se da cuenta de que alguna otra pieza de código se basa en esta función / método de una manera completamente diferente. Luego puede arreglar su prueba y el código resultante. Sin ese tipo de cobertura de código, estarías tropezando durante días tratando de encontrar dónde se rompen las cosas,

Lea sobre "Contratos" en el libro del programador pragmático. Las pruebas lo ayudan a lograr contratos de código. Este código hace X y nada más que X y no esperes que haga nada sobre Y ni intentes adaptarlo para hacer Z. Asegura la limpieza del código y espera que todos no sean un imbécil y enturbien la base del código.

Hay más razones para BDD. La principal para mí es que haría la misma cantidad de pruebas para validar mis suposiciones de todos modos, así que también podría formalizarlo.

Sobre el punto de "cómo" realmente depende de su entorno. Estoy escribiendo un juego de Java ahora y uso robolectric. Siempre debe intentar "esperar" algo. He oído que los espías / simulacros / trozos no son tan útiles ya que necesita tener un equivalente en el otro lado, pero a veces no tiene otra opción, especialmente con las API. Sin embargo, puede suponer que el otro lado de la API no es terrible y generalmente es su código el que apesta.

Si por ejemplo estás probando movimiento. Bueno, cuando se presiona "Arriba", se espera que el usuario avance mediante alguna medición.

Si, por ejemplo, está probando el renderizado de gráficos ... bueno, no lo pruebe demasiado porque realmente lo está haciendo. Un buen marco de prueba podría manejar esta parte por usted. La reflexión no es súper trivial, diría yo para este tipo de cosas. Es posible que necesite verificar los buffers, etc., etc. Simplemente verifico lo que realmente está haciendo. El personaje está aquí, ahora está allí después de alguna acción.

Debe tener muchas pequeñas funciones / pruebas pequeñas y juntas sumarán algo útil.

Siento que hay una idea errónea sobre lo que es BDD. BDD no es una técnica o proceso de PRUEBA. BDD es un modelo y proceso de desarrollo. Va MUCHO más allá de las pruebas y va mucho más allá de la programación.

Como tal, no conozco ningún estudio importante de AAA que trabaje con este modelo (tengo amigos que trabajan para algunos de ellos en todo el mundo como programadores). Como alguien más señaló, puede ser que algún gerente de proyecto o equipo en algún lugar incorpore algunas de las prácticas que abarca BDD, pero no conozco ningún estudio que aplique BDD puro (desde la definición del valor comercial, hasta la especificación, por ejemplo, a la escritura archivos de características, para validarlos con los accionistas, para automatizar los archivos de características como pruebas).