Pregunta

Después de escribir un pequeño artículo sobre BDD, recibí preguntas de personas preguntando si hay casos de uso a gran escala de BDD (y específicamente NBehave).

Entonces mi pregunta va a la comunidad: ¿tiene un proyecto que utilizó BDD con éxito? Si es así, ¿qué beneficios obtuvo y qué podría haber sido mejor? ¿Harías BDD nuevamente? ¿Lo recomendarías a otras personas?

¿Fue útil?

Solución

Hemos utilizado algo de BDD a nivel de código en diferentes escenarios (código abierto y proyectos ND).

  1. Indicando la vista en el escenario MVC, qué tipo de entrada aceptar del usuario ( DDD y validación de UI basada en reglas en .NET )

    result = view.GetData(
      CustomerIs.Valid, 
      CustomerIs.From(AddressIs.Valid, AddressIs.In(Country.Russia)));
    
  2. Informar a la capa de servicio sobre el comportamiento de manejo de excepciones ( ActionPolicy se inyecta en los decoradores):

    var policy = ActionPolicy
      .Handle<WebException>()
      .Retry(3);
    

El uso de estos enfoques ha reducido enormemente la duplicación de código, haciéndolo más estable y flexible. Además, hizo todo más simple, debido a la encapsulación lógica de detalles complejos.

Otros consejos

Estaba en un pequeño equipo que usaba BDD en un sitio web.

La forma en que lo usamos fue esencialmente TDD, pero las pruebas simplemente se escriben como comportamientos usando un DSL. No nos metimos en un gran diseño inicial de comportamientos, pero creamos una gran cantidad de ellos y los usamos exactamente como lo haría con las pruebas.

Como es de esperar, funcionó mucho como TDD, generalmente bueno. Expresar las pruebas como comportamientos fue agradable al interactuar con los clientes y resultó en un documento bastante decente, pero me gustaría que los comportamientos estuvieran escritos en inglés y las pruebas programadas en lugar de tratar de encontrar un lenguaje intermedio difícil que no encaja perfectamente con cualquier propósito.

Todavía sería BDD, solo sin este lindo truco de tratar de torcer el idioma en un lenguaje delineado por un conjunto aleatorio de miradas, en lugar de simples espacios, pero esa era solo mi actitud gruñona de viejo programador, todos los demás eran 100% feliz con eso.

El sitio está disponible y en pleno funcionamiento, por lo que lo llamaría un éxito: Eche un vistazo

Recientemente utilicé el estilo BDD de GWT en un documento de requisitos de alto nivel. No recibí ningún comentario sobre el GWT del cliente que compró a mi jefe dijo que le gustaba, ya que era muy claro y fácil de entender. Tenga en cuenta que no tiene conocimiento de BDD que yo sepa. No puse historias de usuarios ya que esto probablemente hubiera sido un hada demasiado aireada para las personas con un fondo tradicional de cascada. Tal vez intente poner historias de usuarios la próxima vez.

Por cierto, este no fue un proyecto de interfaz de usuario. Fue un proyecto de integración que sincroniza datos de un servicio web en una base de datos. Por lo tanto, muestra que GWT funciona incluso para no "globo ocular". IU.

He estado usando el estilo de especificación de contexto en varios proyectos (usando MSpec) con gran éxito. Todavía estoy tratando de comprender los beneficios reales del estilo Scenario. Cuanto más uso el estilo de especificación de contexto, más me gusta y más estrictas se sienten mis aplicaciones.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top