¿BDD es escalable para proyectos medianos a grandes?

22

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!

DD
fuente
Lástima, creo que este problema es bastante constructivo teniendo en cuenta que BDD está siendo más popular últimamente.
DD
1
Si alguien con suficiente representante puede sugerir una reapertura, sería genial chicos.
DD
Volvería a abrir, pero ya
aceptaste
1
Acepté porque estaba cerrado, así que sabía que no había más respuestas posibles, pero estoy realmente interesado en más informes de experiencia sobre esto, por ahora no lo
aceptaré
2
ok genial :) Creo que también deberías editar un poco la pregunta. Creo que su pregunta es sobre la escalabilidad de BDD en grandes proyectos. "¿Es realmente tan bueno el BDD?" Es subjetivo, "¿BDD se adapta bien a grandes proyectos?" Es un poco más objetivo.
MattDavey

Respuestas:

6

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.

Piotr Perak
fuente
3
TDD no es lo mismo, probar una unidad predefinida nunca puede ser tan complejo a menos que tenga unidades demasiado grandes que huelen a código, pero se supone que las pruebas de integración prueban la interacción entre más de una unidad, una funcionalidad total, esto permite que su complejidad aumente lineal a los requisitos, aún así no se puede romper en pedazos más pequeños, ya que no sería una prueba de inegtración si se hace.
DD
Podría adjuntar algunas pruebas complicadas de BDD y podría ver qué se puede hacer para simplificarlas.
Piotr Perak
No es tan fácil, los que tengo aquí no están en inglés, tendría que traducirlos, si encuentro un requisito que pueda traducir fácilmente al inglés, puedo adjuntarlo, pero aún así el código detrás es un problema que sería demasiado grande para adjuntarlo aquí en una publicación.
DD
¿Por qué se rechazó esto? Le di un gran recurso que ayudará a OP a resolver sus problemas.
Piotr Perak
eso no fue así, daré +1 para compensar, pero solo puedo hacerlo en 14 horas, ya que usé todos mis 30 votos para hoy.
DD
5

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.

Lunivore
fuente
Gracias por esta respuesta informativa, leeré los enlaces que adjuntaste
DD
3

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.

Adrian Schneider
fuente
1

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á!

Ricketyship
fuente
2
Debería elaborar más sobre las diferencias entre BDD y TDD y dónde entra la parte DDD.
Benjamin Gruenbaum
1
@BenjaminGruenbaum Idealmente, no hay diferencia entre BDD y TDD. ¡BDD cuando se sigue correctamente es lo mismo que TDD! Así que no vi ninguna razón para introducir la diferencia como parte de la respuesta. Gracias por la sugerencia sin embargo!
Ricketyship
1
"TDD permite un desarrollo de software más rápido". ¿hubo algún estudio que confirme esto? Sólo curioso. También mencionaría que la aceleración no es lineal.
Den
2
@AlexandreMartins ¡Ja, absolutamente! Es mucho más importante reconocer que es posible que tenga pruebas y escenarios de baja calidad que pretender que todos son buenos IMO.
Lunivore
2
@Lunivore Sí, eso es lo que me molesta en caso de BDD / TDD. Los casos de prueba deben ser fuertes. Desafortunadamente, existe esta opinión en la comunidad de desarrollo de que, siempre que haya casos de prueba, ¡está bien! Una vez vi un caso de prueba en el que se insertaba una fila en una tabla usando una instrucción sql y se afirmaba lo mismo en el siguiente paso. ¿Estaba tratando el desarrollador de probar la funcionalidad de Oracle?
Ricketyship