BDD — Behavior Driven Development
Desenvolvimento Guiado por Comportamento
O BDD é uma técnica de desenvolvimento ágil que integra diferente áreas da empresa onde é dado ênfase no comportamento esperado de uma funcionalidade pelo usuário. Para o Kent Beck, o criador do TDD, os testes devem ser escritos sempre antes de codificado o software, onde eles irão falhar fazendo que o desenvolvedor de acordo com cada cenário falho, fazer que os testes passem, refatore até que fique um código bem limpo. Mas o TDD visa muito nos testes unitários antes de desenvolver qualquer coisa.
O BDD veio para levar o time de desenvolvimento e tester a pensar mais no comportamento do usuário. Trazendo uma linguagem mais fácil de se tratar onde todos os membros do time podem aplica-las, não só o desenvolvedor. O Dan Noth criador do BDD viu os problemas encontrados no TDD e o crio
O QA (Analista de Qualidade), Tester, Q&A, enfim todas as siglas da moda que no fim trata-se de um mesmo setor, onde está crescendo muito hoje em dia no mercado, que é o Setor de Qualidade. As empresas diferentes de alguns anos atrás, vem investindo muito mais nesta fase do desenvolvimento, há um tempo atrás e em algumas empresas, ainda ficava por conta do desenvolvedor testar e assegurar que todas as funcionalidades estão e foram desenvolvidas com uma mínima margem de risco que terá bugs.
A especificação por exemplo tem uma abordagem bem semelhante ao BDD, nela a documentação e bem clara, com uma linguagem natural onde torna-se bem entendida dentro de todo o time, ela é uma boa auxiliar para a implementação do BDD, assim junta-las agrega muito mais valor ao produto final.
Principais vantagens de utilizar o BDD:
· Maior compartilhamento de conhecimento: como estão mais integrados os desenvolvedores e testadores, eles irão trocar muito mais conhecimento entre si do dia a dia.
· Mais comunicação entre a equipe: A uma grande polemica onde o desenvolvedor não gosta do testador e testador não gosta do desenvolvedor, o BDD facilita a integração na equipe, fazendo assim que essa polemica não aconteça, por que os testadores podem criar os cenários e os desenvolvedores implementam.
· Uma documentação mais dinâmica: Sua documentação é mais legível e fácil de entendimento, pois em seus métodos dos testes dizemos como devem ser implementados e como devem se comportar.
· Aumenta a qualidade do software: Como os testes baseia-se no comportamento do usuário, a margem de acontecer um bug no teste de aceitação com o cliente é mínima.
A estrutura do BDD é baseada em três definições:
· Given (DADO): Descrição das condições do cenário
· When (QUANDO): Descrição da ação do cenário quando for executado
· Then (ENTÃO): Descrição do resultado esperado após execução com sucesso do cenário.
Um exemplo seria um teste de login de um usuário:
Funcionalidade: Efetuar login em um dado site.
Cenário: Login com sucesso
· Dado que o usuário acessa o sistema
· Quando insere o seu login e senha
· Então o sistema valida com sucesso o seu acesso.
Como o BDD é baseado nos princípios do TDD, vale lembrar que existe um ciclo semelhante no desenvolvimento guiado por comportamento. Primeiro escreva o teste de acordo com a Feature contendo o comportamento esperado. O teste deve falhar, porque ainda não existe o código. Escreva o código de acordo com o comportamento esperado descrito na Feature. Melhore seu código, refatore e aplique as melhores práticas. O teste deve continuar passando, garantindo que o comportamento não foi alterado.
BDD não é a bala de prata, onde irá resolver todos os seus problemas!
BDD trabalha para definir como uma demanda chega ao desenvolvedor, integrar diferentes áreas da empresa e pensar a partir do ponto de vista do comportamento esperado de uma funcionalidade pelo usuário.
Fontes: https://dtidigital.com.br/blog/bdd-como-metodologia-agil/
http://www.matera.com/blog/post/escrita-de-testes-funcionais-utilizando-semantica-bdd
http://www.matera.com/blog/post/bdd-validando-o-comportamento-sistema