¿BDD es escalable para proyectos medianos a grandes?

En cada sitio web que lee sobre BDD (Behavior Driven Development), encuentra un buen ejemplo muy simple que le muestra cuán obvio y fácil es definir sus requisitos. Pero tratar de implementar este proceso en un gran producto (no un ejemplo de calculadora) me mostró que las cosas pueden volverse (o se volverán) bastante complejas e ilegibles; cambiar especialmente las solicitudes en un momento posterior significa mucho trabajo para corregir las pruebas de integración para esto.

Entonces me pregunto, ¿realmente vale la pena BDD? ¿Resuelve un problema que otras técnicas no lo hacen!

Creo que uno de los mejores recursos en BDD es el libro Especificación por ejemplo . Cuenta mucho acerca de cómo organizar las pruebas de BDD y cómo deben escribirse para que no causen tanto retrabajo cuando cambian los requisitos.

Si las cosas se complican o se complican demasiado en sus pruebas, entonces probablemente esté haciendo algo mal. Es lo mismo con BDD y TDD. Escribir buenas pruebas es difícil y lleva meses aprenderlo.

Puede ser útil darse cuenta de que el enfoque de BDD son las conversaciones . BDD es realmente una herramienta de análisis que proporciona algunas pruebas de regresión como un buen subproducto.

He usado escenarios en todo tipo de niveles en la conversación; desde identificar diferentes partes interesadas para ver si es probable que una publicación sea bien recibida, hasta determinar cómo debe comportarse un módulo o clase .

Hay un par de consejos y sugerencias que puedo sugerir para facilitar esto.

Si nunca lo has hecho antes, va a cambiar.

Es probable que todo lo que sea nuevo para el dominio o el negocio cambie. Puedes darte cuenta de que estás en este espacio si estás hablando de los escenarios, cuestionándolos y el negocio dice: "Oh, no estoy seguro". Esa es una buena señal para dejar de intentar hacer BDD y aumentar algo para obtener comentarios más rápidos, para ayudar a la empresa a resolver lo que quieren. Una vez que las ideas se han estabilizado, los escenarios se pueden escribir en retrospectiva.

Todos los proyectos tienen algún aspecto nuevo, o no los estarías haciendo.

Si lo has hecho antes, es aburrido.

Además de los aspectos nuevos y diferenciadores , los proyectos generalmente tienen algunos aspectos comercializados que son similares a los ya realizados. Por ejemplo, si estaba produciendo un nuevo teléfono móvil, aún tendría que hacer llamadas. "Hacer una llamada telefónica" es un escenario tan conocido que no tendríamos que hablarlo. Del mismo modo, cosas como "iniciar sesión" o incluso "registro de usuario" son aburridas.

Siempre que sea posible, use bibliotecas para estos, y luego no tendrá que escribir escenarios a su alrededor. Además, ¿los otros bits primero - haber un ya-usuario conectado y el trabajo lo que el registro está en para . Es poco probable que estas áreas cambien, por lo que es posible que pueda salirse con las pruebas manuales de todos modos.

Si alguien lo ha hecho antes, hablar sobre los escenarios puede ayudar.

Hay un poco entre donde tenemos requisitos específicos de dominio, cosas que es relativamente bien entendido por alguien , y donde la incertidumbre real se basa principalmente en el alcance en lugar del comportamiento real del sistema.

Hablar a través de escenarios puede ayudar al equipo de desarrollo a descubrir comportamientos, aprovechar el conocimiento de un experto y garantizar que se capture el comportamiento conocido y valioso.

Este es el bit donde BDD funciona mejor. Mi consejo es escribir los escenarios más interesantes en la parte superior del archivo de características (o wiki, si no está automatizando) y eliminar cualquier escenario que esté duplicado o sea fácil de inferir como resultado.

Siempre que sea posible, use los escenarios solo como ejemplos de cómo funciona la aplicación . Por ejemplo, si desea mostrar cómo funciona la validación, muestre un par de ejemplos de cómo la aplicación ayuda al usuario a completar un formulario. Verifique que la validación sea rigurosa utilizando pruebas unitarias, que son mucho más fáciles de mantener y más rápidas de ejecutar.

Otras lecturas

Si está interesado en esto, aquí hay algunas cosas que escribí que podrían ayudar.

BDD en el grande

Cynefin para desarrolladores , que aborda estas tres áreas con más detalle

Mis diapositivas de tutoriales , que son agradables y anotadas para ti, y cubren toda la pila también.

Construimos un proyecto bastante complejo ( complejidad de dominio ) el otoño pasado y puedo decir honestamente que poner el trabajo inicial en BDD salvó el proyecto. He visto una fuerte correlación entre la complejidad del dominio y los beneficios de BDD.

Permítanme aclarar una cosa: probar reglas comerciales complejas es difícil. La pregunta es, ¿quieres probar y recordar todos los escenarios locos cada vez que realices un cambio, o quieres que esa red de seguridad te avise cuando hayas incumplido las especificaciones? Pase el tiempo inicial y resuelva todos los escenarios, escríbalos y, finalmente, escriba todas las pruebas para ellos.

Y cuando vuelves más tarde tratando de darle sentido a las cosas, tener esa especificación comprobable es un salvavidas.

BDD es un proceso de desarrollo basado en TDD (Test Driven Development) Estos son algunos de los pros y los contras de TDD extraídos de mi experiencia personal:

• TDD, se asegura de que su alcance esté bien definido. De esta manera, primero diseñas tus casos de prueba. Por lo tanto, establezca una expectativa para el fragmento de código que se supone que debe escribir.
• TDD es una forma de proteger su código. Suponga que escribe una función simple y luego agrega alguna condición de conmutación compleja en esta misma función. Mañana, si alguien más quiere modificar esta función, puede consultar el caso de prueba. Si quiere cambiar su función, entonces también tiene que cambiar el caso de prueba (la mayoría de las veces). Esto le permite comprender que había un razonamiento detrás de lo que escribió.
• TDD permite un desarrollo de software más rápido. Cada uno de nosotros habría enfrentado este problema mientras codificaba. Comenzamos con una idea. Y poco a poco lo pierdes de vista. Terminamos poniendo piezas de código no deseadas para manejar algunos escenarios. En TDD, establece las expectativas por adelantado. De este modo, te limitas a alejarte demasiado del objetivo.
• TDD le permite detectar posibles errores antes de que el proyecto se ponga en línea. Esto tiene que ver principalmente con la calidad de los casos de prueba que están escritos.

Contras:

• Al principio, TDD puede ser un poco complicado. Muchas personas no entienden el concepto de un caso de prueba que impulsa el desarrollo.
• TDD, a veces puede conducir a enormes esfuerzos en mantenimiento. Esto tiene que ver con casos de prueba no deseados o sin sentido.
• TDD tiene que tomarse con una pizca de sal. A ningún desarrollador le gusta pasar tiempo en algún caso de prueba escrito por otra persona. Descifrar el significado del caso de prueba a veces puede causar un gran dolor de cabeza.

Trabajo en un proyecto con más de 900,000 líneas de código. Y todavía sigo con BDD. Una cosa importante que debe tener en cuenta es la cantidad de posibles errores que puede detectar simplemente debido a los casos de prueba. ¡Unos años más adelante, BDD jurará!