Me encanta el enfoque de desarrollo de la BDD, pero me he topado con una preocupación con respecto a qué tan lejos ir. Este comentario de ThoughtWorks más reciente.Radar me da una pausa

"La llegada de los marcos de prueba de diseño impulsado por comportamiento (BDD) como Cucumber, combinados con herramientas de automatización del navegador como Selenium, ha fomentado el uso generalizado de las pruebas de aceptación a nivel del navegador. Esto desafortunadamente alentó hacer la mayor parte de las pruebas donde el costo para ejecutar el las pruebas son las mejores. En su lugar, debemos realizar las pruebas en el nivel apropiado, lo más cerca posible del código, de modo que las pruebas puedan ejecutarse con la máxima eficiencia. Las pruebas a nivel del navegador deben ser la guinda del pastel, respaldadas por la aceptación y la unidad Pruebas ejecutadas en capas apropiadas ".

Así que aquí está mi escenario (juego de palabras destinado):

Tengo una aplicación básica de CRUD con un requisito comercial para filtrar los datos que se muestran según los criterios que el usuario final puede seleccionar. Para facilitar la discusión, digamos que es una aplicación para la compañía eléctrica, y estoy mostrando el consumo de energía actual hasta el mes de cada cliente. El usuario de esta aplicación podría restringir los datos seleccionando un solo cliente, varios clientes, ningún cliente o "Todos los clientes". Los datos mostrados cambiarán según lo que seleccionen.

Para un actor del producto, estos representan realmente 4 escenarios diferentes. Sin embargo, desde la perspectiva del desarrollador, son prácticamente idénticos, y la única diferencia es que un parámetro se pasa a la base de datos. Entonces, la pregunta es: ¿el beneficio de tener cada permutación explicada es mayor que el costo de correr y mantenerlas?

Creo que los principios de la BDD probablemente dirían "sí" porque la comunicación del comportamiento esperado es más explícita, pero no estoy seguro. Ciertamente me da la sensación de exceso. Los escenarios probablemente serían una gran cantidad de copiar y pegar con cambios menores.

Mi inclinación es cubrir esta funcionalidad con un solo escenario que capture el valor comercial central ("cuando selecciono un cliente, veo los datos de uso de energía"), y luego cubro las otras permutaciones con un conjunto de pruebas de integración no basadas en UI que validar el servicio / consulta devuelve los datos correctos. ¿Está mal pensar esto? ¿Cuál es la mejor respuesta para asegurarse de que estos escenarios estén cubiertos, sin renunciar a los beneficios de la BDD?