Neste artigo, veremos uma nova técnica para desenvolvimento ágil conhecida como Behaviour Driven Development (ou BDD). Mostraremos com exemplos práticos como BDD encoraja a colaboração entre desenvolvedores, setores de qualidade e pessoas de negócios em um projeto de software.

Antes, vamos entender o que é TDD!

Test Driven Development(TDD) ou, em português,Desenvolvimento Dirigido por Testesé uma técnica de desenvolvimento de software que se baseia em um ciclo curto de repetições. Primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade. Então, é produzido código que possa ser validado pelo teste. Posteriormente este código será refatorado para colocá-lo sob padrões aceitáveis.

Kent Beck declarou em 2003 que TDD encoraja designs de código simples e inspira confiança. Do ponto de vista de Robert C. Martin, escritor do livro “Agile Software Development”, o objetivo de TDD é a especificação e não a validação, ou seja, é a maneira de pensar através das necessidades do projeto antes de escrever o código funcional.

Para que serve?

BDD serve para criar testes e integrar regras de negócios com a linguagem de programação, focando no comportamento do software. Além disso, ainda melhora a comunicação entre as equipes de desenvolvimento e testes, aumentando o compartilhamento de conhecimento entre elas.

Quando usar?

Esta metodologia é útil em projetos de software ágeis, que são construídos em várias iterações e estão sofrendo alterações ao longo do seu ciclo de vida. Quanto maior o projeto, mais difícil será a comunicação. Entretanto, BDD propõe uma forma eficaz de resolver estes problemas.

BDD, a evolução

BDD é técnica de desenvolvimento ágil que visa integrar regras de negócios com linguagem de programação, focando o comportamento do software. Além disso, pode-se dizer também, que BDD é a evolução do TDD. Isto porque, os testes ainda orientam o desenvolvimento, ou seja, primeiro se escreve o teste e depois o código.

O foco em BDD é a linguagem e as interações usadas no processo de desenvolvimento de software. Desenvolvedores que se beneficiam destas técnicas escrevem os testes em sua língua nativa em combinação com a linguagem ubíqua(Ubiquitous Language). Isso permite que eles foquem em por que o código deve ser criado, ao invés de detalhes técnicos, e ainda possibilita uma comunicação eficiente entre as equipes de desenvolvimento e testes.

A linguagem de negócio usada em BDD é extraída das estórias ou especificações fornecidas pelo cliente durante o levantamento dos requisitos. Alguns frameworks utilizam o conteúdo das estórias escritas em um arquivo de texto como cenários para os testes. Quando Dan North apresentou este conceito em 2003, ele sugeriu um padrão para escrita destes arquivos. Veja na Figura 1. Este é apenas um modelo, ou seja, não é obrigatório. Entretanto, Dan North denota que é extremamente importante a equipe seguir um padrão para facilitar a comunicação entre os envolvidos no projeto.

O primeiro framework de BDD, JBehave, foi criado por Dan North, seguido de um framework em Ruby chamado RBehave, o qual foi depois incorporado ao projeto RSpec. Ele também trabalhou com David Chelimsky, Aslak Hellesøy entre outros para desenvolver o framework RSpec e também escrever o livro “The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends”.

Vantagens em usar BDD

Quando Dan North fala sobre BDD, ele sempre esclarece que o propósito não é anular as práticas de TDD, muito pelo contrário, é adicionar a elas uma série de outras vantagens, dentre as quais se podem listar:

• Comunicação entre equipes: na maioria das empresas de desenvolvimento de software é difícil fazer com que desenvolvedores e testadores trabalhem em conjunto para atingir um objetivo. BDD possibilita esta integração porque os testadores podem escrever os cenários de testes para os desenvolvedores implementarem;

• Compartilhamento de conhecimento: com desenvolvedores e testadores trabalhando juntos, ao longo do tempo, um irá transferir o seu conhecimento para o outro, criando assim uma equipe multifuncional;

• Documentação dinâmica: algumas equipes ágeis afirmam que não documentam o sistema porque a manutenção destes artefatos é custosa. Usando os frameworks de BDD estes artefatos são gerados dinamicamente sem nenhum esforço adicional. Alguns, inclusive, geram relatórios em formato HTML, o que irá facilitar uma consulta posterior;

• Visão do todo: Fergus O’Connell, em sua obra “How to Run Successful High-Tech Project-Based Organizations”(Artech House, 1999), apresenta uma relação dos principais motivos que levamprojetos de software ao fracasso. O primeiro deles é: “os objetivos do projeto não são bem definidos e compartilhados entre todos os envolvidos”. Por este motivo, BDD sugere que os analistas/testadores escrevam os cenários antes mesmo dos testes serem implementados, e desta forma os desenvolvedores terão uma visão geral do objetivo do projeto antes de codificá-lo.

Não restam dúvidas de que desenvolver uma aplicação guiada por testes é uma prática extremamente benéfica. O resultado é um código de boa qualidade, alta coesão e com número reduzido de bugs, com isso proporcionando um prazo de validade longo e manutenções mais baratas no futuro. No entanto, iniciar no mundo dos testes não é nada fácil.