Pode ajudar a perceber que o foco do BDD são as conversas . O BDD é realmente uma ferramenta de análise que fornece alguns testes de regressão como um bom subproduto.
Eu usei cenários em todos os tipos de níveis na conversa; desde a identificação de diferentes partes interessadas para ver se é provável que uma versão seja bem recebida, até a elaboração de como um módulo ou classe deve se comportar .
Existem algumas dicas e sugestões que posso sugerir para facilitar isso.
Se você nunca fez isso antes, isso vai mudar.
Qualquer coisa nova no domínio ou nos negócios provavelmente mudará. Você pode perceber que está nesse espaço se estiver falando dos cenários, questionando-os e os negócios disserem: "Oh, não tenho certeza". Esse é um bom sinal para parar de tentar fazer BDD e gerar algo para obter um feedback mais rápido, para ajudar a empresa a descobrir o que eles querem. Depois que as idéias se estabilizarem, os cenários podem ser escritos em retrospecto.
Todos os projetos têm algum aspecto novo, ou você não os faria.
Se você já fez isso antes, é chato.
Além dos aspectos novos e diferenciadores , os projetos geralmente têm alguns aspectos comoditizados, semelhantes aos já realizados. Por exemplo, se eu estivesse produzindo um novo celular, ele ainda precisaria fazer chamadas. "Fazer uma ligação" é um cenário tão conhecido que não precisaríamos conversar sobre isso. Da mesma forma, coisas como "login" ou mesmo "registro de usuário" são chatas.
Sempre que possível, use bibliotecas para elas e, em seguida, você não precisará escrever cenários em torno delas. Além disso, fazer os outros bits em primeiro lugar - têm um já-usuário conectado e trabalhar para fora o que logging ele está em para . É improvável que essas áreas sejam alteradas; portanto, você pode se safar dos testes manuais de qualquer maneira.
Se alguém já fez isso antes, conversar através de cenários pode ajudar.
Há um pouco entre onde temos requisitos específicos de domínio, coisas que são relativamente bem entendidas por alguém e onde a incerteza real está principalmente no escopo, em vez do comportamento real do sistema.
Conversar através de cenários pode ajudar a equipe de desenvolvimento a descobrir comportamento, aproveitar o conhecimento de um especialista e garantir que o comportamento conhecido e valioso seja capturado.
É aqui que o BDD funciona melhor. Minha dica é escrever os cenários mais interessantes na parte superior do arquivo de recursos (ou wiki, se você não estiver automatizando) e excluir os cenários duplicados ou fáceis de inferir como resultado.
Sempre que possível, use os cenários apenas como exemplos de como o aplicativo funciona . Por exemplo, se você quiser mostrar como a validação funciona, mostre alguns exemplos de como o aplicativo ajuda o usuário a preencher um formulário. Verifique se a validação é rigorosa usando o teste de unidade, que é muito mais fácil de manter e mais rápido de executar.
Leitura adicional
Se você está interessado nisso, aqui estão algumas coisas que escrevi que podem ajudar.
BDD nas grandes
Cynefin para desenvolvedores , que aborda essas três áreas com mais detalhes
Meus slides do tutorial , todos agradáveis e anotados para você, cobrem toda a pilha também.