A prática do Behavior-Driven Development (BDD) frequentemente vai contra as práticas usuais no mercado. Joe Colantonio elabora esta conclusão ao apontar seis problemas frequentes e como contorná-los, compartilhando suas experiências e discussões com líderes da filosofia BDD.
Mantenha seu BDD livre de detalhes de implementação. Incluir detalhes de implementação, por exemplo, botões de uma interface gráfica, vai dificultar a manutenção de cenários e funcionalidades. O foco deve estar no "o quê", ao invés do "como", ao se pensar nas ações do usuário. Uma forma de fazer isso é manter um estilo mais declarativo ao invés de imperativo ao escrever cenários. Colantonio aponta que uma razão para equipes incluírem detalhes de implementação é o uso do BDD como um framework de automação de testes, ao invés de usar como uma ferramenta de colaboração (propósito original do BDD).
A automação é um benefício colateral, não a razão principal para se usar o BDD. Colantonio faz referência à Seb Rose que afirmou que quando a colaboração com pessoas responsáveis pelo negócio ou clientes falha é um anti-pattern utilizar BDD como uma ferramenta para automação de testes. Aslak Hellesoy, que criou a ferramenta BDD Cucumber em 2008, enfatiza que o Cucumber primeira e principalmente é uma ferramenta de colaboração que visa gerar uma compreensão comum entre todos os membros de uma equipe. A descrição de uma funcionalidade utilizando o Cucumber deve ser escrita antes da codificação da mesma. Ao trabalhar com BDD escrevendo cenários, testes de regressão são um sub-produto. O teste não é o objetivo principal.
A troca de idéias é tudo. Para Colantonio a beleza do BDD está no fato de haver a chance de corrigir conclusões precipitadas e mal-entendidos, além de permitir encontrar bugs potenciais antes de escrever código. No entanto, ele acredita que colocar o foco na comunicação ao invés de colocá-lo na escrita de requisitos é um novo paradigma para algumas equipes. Como consequência, Colantonio aponta que equipes migrando para o BDD e Agile devem cuidar para não tratar cenários como requisitos.
Um cenário não é um requisito. Requisitos e cenários estão relacionados uma vez que um conjunto de cenários corresponde a um requisito. Para Colantonio tratar cenários como requisitos pode trazer problemas. Ele prefere a prática BDD de criar pequenos exemplos numa discussão com o product owner, uma técnica descrita por Gojko Adzic no livro Specification by Example.
Não transforme tudo em testes de interface do usuário. Cenários são escritos do ponto de vista de um usuário. No entanto, Colantonio diz que isso não significa que a funcionalidade deve ser testada através da interface gráfica. Testar componentes sem passar pela interface de uma aplicação é mais rápido e produz testes mais robustos. Recentemente Konstantin Kudryashov explicou como o BDD pode ser usado com o Domain-Driven Design (DDD) para diminuir o número de cenários com foco na interface. Ao verificar que o domínio funciona, apenas cenários críticos para o funcionamento da interface serão adicionados.
Usar o Scrum não significa que está sendo Ágil. A utilizar o Scrum, equipes frequentemente pensam que estão automaticamente sendo ágeis, mas Colantonio acredita que com muita frequência esse não é o caso. Escrever testes unitários depois de codificar ou criar testes de aceitação e integração posteriormente a implementação da funcionalidade, às vezes usando outra equipe para codificação dos testes, são sinais que indicam que a equipe não segue uma abordagem Agile.