O BDD (Behavior Driven Development)
É uma técnica de desenvolvimento Ágil de software, que encoraja colaboração entre desenvolvedores, setores de qualidade e pessoas não-técnicas ou de negócios num projeto de software, relaciona-se com o conceito de verificação e validação.
BDD é uma técnica de desenvolvimento de software ágil que surge através de uma crítica de Dan North ao Test Driven Development(Desenvolvimento orientado a testes), onde ele visava otimizar o conceito de ‘verificação e validação’ já aplicado, e tornar mais eficiente a construção de cenários a serem testados e/ou desenvolvidos.
Para Kent Beck, criador do TDD, os testes devem ser escritos antes do código do software, assim irão falhar. Logo após, os desenvolvedores irão se basear nestes cenários falhos, irão implementar a aplicação de maneira a fazer os testes passar, e refatorar seu código até que fique mais limpo. De maneira cíclica. O que foi chamado de Red-Green- Refactor.
O BDD é uma técnica que foca no comportamento do software, com essa metodologia podemos criar testes e integrar as regras de negocio com a programação. A definição do comportamento geralmente é realizada por user stories onde os cenários devem ser escritos de uma forma curta com uma descrição simples da feature.
Ao contrário do que alguns podem pensar, esse conceito não se aplica apenas a profissionais de qualidade, mas para sua correta implantação todos os membros do time precisam entendê-lo, e estar comprometidos com um pensamento que gira em torno das necessidades de um usuário real.
O BDD deveria ser utilizado para verificar as partes mais importantes do aplicativo utilizando testes end-to-end, para os testes de integração, que a escrita devem ser simples, mas de modo que faça sentido para o negócio.
O BDD deverá ser aplicado em testes de unidade desde que haja beneficio para o negócio, quando precisamos validar o comportamento de uma aplicação.
O BDD não é necessário em testes unitários que validem a implementação real, pois dessa forma seria um obstáculo a sua reformulação, uma vez que estes testes não passam por validação de um Stakeholder por serem escritos em códigos e a maioria dos Stakeholders não validam código.
Em todo e qualquer projeto deve sempre haver uma cooperação muito grande com o negócio, além disso a implementação do BDD é documentar o sistema de modo que qualquer pessoa do time possa e consiga ler o teste.
O foco do BDD é a prevenção de falhas de comunicação, onde nesta metodologia as equipes sofrem frequentemente com um processo de comunicação baseados em exemplos reais, pois assim todas as experiências reais são trazidas e compartilhadas entre todos. A equipe de negócio pode somar seu conhecimento do negócio com a capacidade e domínio técnico das técnicas de desenvolvimento de software na elaboração das estórias.
O principal ganho deste processo é que os Analistas de Negócio podem expandir mais o seu conhecimento entendendo a técnica aplicada em cada cenário, e os desenvolvedores e os Quality Assurance podem ter uma ideia mais clara das necessidades do negócio.
Então o que podemos resumir é que ferramentas de BDD são complementares á essa metodologia ágil, utilizar de uma ferramentas de automação ou escrever os testes em Gherkin são apenas parte do processo.
E está correto, porém a grande vantagem desta prática não é gerar testes, e sim pensar no design e nas regras negócios antes de escrever qualquer linha de código.
Assim surge o BDD, como uma prática que levaria o time de desenvolvimento a pensar no comportamento do usuário para entender o que deve ser feito. E atualmente através de conceitos e ferramentas, ele já pode ser aplicado por todos os membros do time, e não apenas pelos desenvolvedores.
O BDD apresenta um framework baseado em três princípios:
- .A área de negócios e o time de desenvolvimento precisam se referir a mesma parte do sistema da mesma forma;
- Toda parte do sistema precisa ter um valor identificável e verificável para o negócio;
- Analisar, projetar e planejar tudo de cima a baixo tem retorno decrescente;
Podemos definir o BDD como a união de várias práticas consideradas ágeis e úteis no desenvolvimento de software, cuja ênfase está nas funcionalidades de alto valor e na redução dos custos de mudança por meio da identificação do que de fato está sendo testado/desenvolvido.
