O Cucumber não serve apenas para automatizar testes, é possível fazer melhor que isso. Escrever cenários que ilustrem as regras de negócio, ao invés de funcionalidades da interface, permite envolver analistas de negócios escrevendo cenários antes do desenvolvimento, fazendo com que os desenvolvedores sejam guiados por uma especificação sem ambiguidade. Usando, portanto, o Desenvolvimento Orientado ao Comportamento (Behavior-Drive Development - BDD), que Aslak Hellesøy descreve, refletindo sobre sua experiência na qual pode ver o mau uso e má compreensão.
Hellesøy, que criou o Cucumber em 2008 com 5 milhões de downloads durante os três primeiros anos, enfatiza que o Cucumber é principalmente uma ferramenta de colaboração com a intenção de criar um entendimento comum entre todos os membros da equipe. No Cucumber as funcionalidades devem ser escritas antes do desenvolvimento. Quando se trabalha com os exemplos de escrita do BDD, testes de regressão são uma consequência, e não a atividade principal.
Olhando para o Cucumber para JavaScript, Julien Biezemans enxerga benefícios no BDD vindo para o desenvolvimento web, mas destaca que os mesmos mal entendidos que Hellesøy menciona, como o uso do Cucumber apenas como uma ferramenta de teste, são comuns também no desenvolvimento web. Para Biezemans, BDD é sobre encorajar conversar entre os envolvidos, anotando exemplos que tornem as coisas claras e reduza a ambiguidade permitindo que todos concordem com o que está sendo construído. Automação dos cenários levantados nas conversa é um próximo passo opcional.
Hellesøy declarou no último ano que para usar o Cucumber é necessário fazer parte de um processo que envolva a maioria das pessoas em uma equipe de desenvolvimento de software. BDD é o processo que mais tarde foi renomeado por Gojko Adzic para Especificação por Exemplos (Specification by Example). Simplificando, esse processo consiste em duas atividades principais:
- Workshops de especificação em que analistas de negócios responsáveis pelos requisitos, junto com os desenvolvedores e testadores, discutem as funcionalidades que serão desenvolvidas, (estes três papéis pode ser chamado de os três amigos). Ao mesmo tempo, eles escrevem exemplos de como o software deve se comportar, em estrutura de cenários do Cucumber.
- O desenvolvimento é feito de fora para dentro, assim os desenvolvedores escrevem o código de forma incremental e executam os cenários do Cucumber que foram criados previamente, até que a funcionalidade passe por todos os testes. Os desenvolvedores tipicamente começam com funcionalidades para o usuário para irem aprofundando até o núcleo principal, portanto até o nome dos métodos.
Liz Keogh observa que a definição de BDD é difícil; com uma metodologia derivada de vários outros métodos e filosofias tornando difícil definir uma fronteira do que é e do que não é. Ao invés disso Keogh pensa no BDD como um termo âncora, no qual o centro é a comunicação, colaboração e detalhamento de cenários juntamente com sua automação. Em torno disso, há uma séria de outras práticas como as mencionadas por Hellesøy e outras ferramentas, incluindo o Cucumber, Jbehave e SpecFlow. Concluindo, Keogh defini BDD em uma idéia principal:
Utilização de exemplos em conversas para ilustrar o comportamento.