O que é BDD?

O Behavioral Driven Development (BDD) é uma abordagem de desenvolvimento de software que evoluiu do TDD (Test Driven Development). Difere por ser escrito em um idioma compartilhado, o que melhora a comunicação entre equipes e partes interessadas, técnicas e não técnicas. Nas duas abordagens de desenvolvimento, os testes são escritos à frente do código, mas no BDD, os testes são mais focados no usuário e baseados no comportamento do sistema.

O BDD aumenta o TDD e o ATDD com as seguintes táticas:

• Aplique o princípio “Five whys” a cada história de usuário proposta, para que seu objetivo esteja claramente relacionado aos resultados dos negócios;
• pensar “de fora para dentro”, ou seja, implementar apenas os comportamentos que contribuem mais diretamente para esses resultados de negócios, de modo a minimizar o desperdício;
• descrever comportamentos em uma única notação que seja diretamente acessível a especialistas, testadores e desenvolvedores de domínio, para melhorar a comunicação;
• aplique essas técnicas até os níveis mais baixos de abstração do software, prestando atenção especial à distribuição do comportamento, para que a evolução permaneça barata.

Porquê usar o BDD?

O TDD funciona satisfatoriamente, desde que o proprietário da empresa esteja familiarizado com a estrutura de teste de unidade sendo usada e suas habilidades técnicas sejam suficientemente fortes, o que nem sempre é o caso. Nessas circunstâncias, o BDD tem a vantagem porque os casos de teste podem ser escritos em um idioma comum usado pelas partes interessadas, como, por exemplo, o inglês. Esse acesso a uma comunicação mais clara e com pouco jargão é provavelmente a maior vantagem do uso do BDD, possibilitando que a colaboração entre as equipes técnica e não técnica funcione com maior eficiência.

O que esperar do BDD?

Como descrito acima, a vantagem de os casos de teste do BDD serem escritos em um idioma comum é que os detalhes de como o aplicativo se comporta podem ser facilmente compreendidos por todos. Por exemplo, os casos de teste podem ser escritos usando exemplos em tempo real dos requisitos reais, para explicar o comportamento do sistema.

As equipes que já usam TDD ou ATDD podem considerar o BDD por vários motivos:

• O BDD oferece orientação mais precisa sobre a organização da conversa entre desenvolvedores, testadores e especialistas em domínio;
• As notações originárias da abordagem BDD, em particular a tela dada quando, estão mais próximas da linguagem cotidiana e têm uma curva de aprendizado mais rasa em comparação com as de ferramentas como Fit / FitNesse;
• As ferramentas direcionadas a uma abordagem BDD geralmente oferecem a geração automática de documentação técnica e do usuário final a partir das “especificações” do BDD.

Quais os pré requisitos para utilização do BDD?

• Os requisitos devem ser convertidos em histórias de usuários que possam definir exemplos concretos;
• Cada exemplo deve ser um cenário de usuário válido, em vez de um mero caso de teste;
• Um entendimento da matriz “função-recurso-razão” e a fórmula “determinado quando então”;
• Consciência da necessidade de escrever “a especificação do comportamento de uma classe” em vez de “o teste de unidade de uma classe”.

Quais as possíveis armadilhas?

Embora Dan North, que formulou a abordagem do BDD pela primeira vez, afirme que ela foi projetada para abordar questões recorrentes no ensino do TDD, é claro que o BDD exige familiaridade com uma gama maior de conceitos do que o TDD, e parece difícil recomendar a um programador iniciante que deve primeiro aprender BDD sem exposição prévia aos conceitos de TDD.

O uso do BDD não requer ferramentas ou linguagens de programação específicas e é principalmente uma abordagem conceitual; torná-lo uma prática puramente técnica ou que depende de ferramentas específicas seria errar completamente o ponto.

Ferramentas BDD

Cucumber

Cucumber é uma estrutura de teste que suporta BDD. No Cucumber, as especificações do BDD são escritas em inglês simples e prático, definido pela linguagem Gherkin. Gherkin apresenta o comportamento do aplicativo usado, a partir do qual o Cucumber pode gerar os casos de teste de aceitação. Ele possui uma estrutura desenvolvida por Ruby que pode funcionar em diferentes tecnologias.

Speckflow

O Specflow evoluiu da estrutura do Cucumber usando Ruby on Rails e é usado principalmente para projetos .Net. Ele usa também a linguagem Gherkin.

Resumindo… Vale a pena?

O BDD nos permite desenvolver, testar e pensar sobre o código do ponto de vista do proprietário da empresa. Você precisa ter a mentalidade de implementar “exemplos em tempo real” em vez de implementar apenas “funcionalidades”. Experimente!