Eu estou amando a abordagem do BDD para o desenvolvimento, mas me deparo com uma preocupação com o quão longe de ir. Este comentário da ThoughtWorks mais recenteRadar me dá uma pausa:

"O advento de estruturas de teste de design orientado a comportamento (BDD) como o Cucumber, combinado com ferramentas de automação de navegador como o Selenium, encorajou o uso disseminado de testes de aceitação no nível do navegador. Isso infelizmente encorajou a maioria dos testes Em vez disso, devemos testar no nível apropriado, o mais próximo possível do código, para que os testes possam ser executados com a máxima eficiência. Os testes no nível do navegador devem ser a cereja no topo do bolo, apoiados por aceitação e unidade. testes executados em camadas apropriadas ".

Então aqui está meu cenário (trocadilho intencional):

Eu tenho um aplicativo CRUD básico com um requisito de negócios para filtrar os dados exibidos com base em critérios que o usuário final tem permissão para selecionar. Para facilitar a discussão, digamos que é um aplicativo para a empresa de energia e estou exibindo o consumo atual de energia do mês para cada cliente. O usuário desse aplicativo pode restringir os dados selecionando um único cliente, vários clientes, nenhum cliente ou "Todos os clientes". Os dados exibidos serão alterados com base no que eles selecionam.

Para uma parte interessada do produto, estas representam realmente 4 cenários separados. No entanto, do ponto de vista do desenvolvedor, eles são praticamente idênticos, com a única diferença sendo um parâmetro passado para o banco de dados. Então a questão se torna: o benefício de ter cada permutação explicada supera o custo de administrá-los e mantê-los?

Acho que os princípios do BDD provavelmente diriam "sim" porque a comunicação do comportamento esperado é mais explícita, mas não tenho certeza. Certamente tem a sensação de um exagero. Os cenários provavelmente seriam um monte de copiar e colar com pequenas alterações.

Minha inclinação é cobrir essa funcionalidade com um único cenário que captura o valor comercial principal ("quando eu seleciono um cliente eu vejo os dados de uso de energia") e, em seguida, cobro as outras permutações com um conjunto de testes de integração não baseados em UI que validam o serviço / consulta retorna os dados corretos. Isso está errado? Qual é a melhor resposta para garantir que esses cenários sejam cobertos, sem renunciar aos benefícios do BDD?