BDD – Behaviour Driven Development – é uma técnica ágil que está bastante relacionada aos posts publicados na semana passada: User Stories – O Que São? Como Usar? e Critérios de Aceitação das User Stories.

Segundo Dan North, seu criador, BDD é uma evolução de outra técnica ágil chamada TDD – Test Driven Development. Ela foi criada com o objetivo de facilitar o entendimento de TDD para aqueles que estão começando a lidar com o desenvolvimento dirigido por testes e, ao meu ver, acabou se tornando mais eficaz que a técnica que a originou. Isso porque BDD é uma técnica cujo foco está em avaliar o comportamento do sistema e não em gerar testes apenas. Esta nova visão faz com que os testes sejam apenas uma consequência necessária para garantir que o seu sistema esteja de acordo com as user stories e com os critérios de avaliação levantados pelo PO.

O primeiro benefício de BDD para o desenvolvimento ágil está em direcionar os programadores na criação dos testes. Não existirão mais dúvidas como: Como devo chamar o teste criado? O que devo testar? Até quando devo testar?. O foco agora está em testar o que realmente importa para o usuário e verificar que o que ele espera do sistema esteja de fato acontecendo. Não será mais necessário buscar o que deve ser testado, as user stories e os critérios de avaliação dirão isso para os desenvolvedores.

Outro ponto positivo é que seus testes estarão focados no que realmente tem valor para o usuário e, portanto, será mais fácil convencer o PO de que o tempo utilizado na criação de testes não é tempo perdido. A qualidade do seu sistema melhorará e impactará diretamente na experiência do usuário, o que, sem dúvida, será bastante valorizado pelo PO.

O processo de BDD é simples e se assemelha bastante ao fluxo de TDD. A partir da user story, como a apresentada abaixo, é possível identificar o papel que executará uma funcionalidade em busca de um resultado.

A partir daí, o próximo passo é criar o teste que garantirá que o código implementado está de acordo com o que foi especificado. Lembrem-se que o foco deve estar no comportamento, então nada além do que está previsto na user story e nos critérios de aceitação deve ser levado em consideração. Com os testes criados, é o momento de codificar a funcionalidade de forma que ela passe no teste gerado previamente. Vale também ressaltar que esses testes não devem ser esquecidos em algum lugar do projeto. A cada novo release é necessário rodar todos os testes para verificar se as funcionalidades continuam funcionando corretamente. Em alguns casos, a especificação pode mudar. Caso isso aconteça, o teste também deve ser atualizado.

Esse processo pode ser apoiado por frameworks como o JBehave. Focado para desenvolvimento de BDD em Java, ele permite criar os testes a partir da descrição textual do que deve ser testado. No entanto, nada impede que os testes sejam criados com o que já conhecemos, como o JUnit. É apenas uma questão de opção da equipe.

No fim, a pergunta que fica é: BDD resolverá todos os meus problemas? Não. É preciso avaliar se outras técnicas de testes já conhecidas se adequam melhor aos seus projetos. Em alguns casos, será necessário criar testes mais focados na implementação e na verificação de determinada parte do código. No entanto, acredito que BDD pode sim agregar mais valor ao produto e evidenciar para o PO as melhorias que as equipes já sabem que os testes trazem. Além disso, ele pode tornar o desenvolvimento dirigido por testes mais amigável para os desenvolvedores.

Referências: Bevahiour Driven Development