A presença de profissionais com habilidades e especializações distintas tende a trazer grande riqueza e versatilidade no desenvolvimento de projetos, mas apresenta um desafio típico: fazer com que todos consigam “conversar” entre si, orientando seus esforços para entregar o resultado desejado pelos stakeholders.

No universo do desenvolvimento de softwares, a prática do BDD (Behavior Driven Development – Desenvolvimento Guiado por Comportamento, em tradução livre) surge como uma valiosa ferramenta para enfrentar este desafio.

Idealizado por Dan North em meados de 2003, o BDD pode ser entendido como um “passo além” do TDD (Test Driven Development – Desenvolvimento Guiado por Testes), uma abordagem segundo a qual “tudo deve ser testado antes de ser desenvolvido”. Em seu trabalho, North chegou à conclusão de que focar primariamente em testes tende a atravancar o processo, gerando um excesso de documentação e dificultando a comunicação entre os membros da equipe.

Este é o tema do webinar BDD Não é Caso de Teste!, ministrado por [Nome e cargo], e que pode ser acessado clicando aqui.

Desenvolvimento para todos

A proposta do BDD é basear o desenvolvimento do software em cenários que descrevem como a aplicação (ou unidade de código) deverá se comportar em determinada situação. A descrição desse comportamento esperado pode (“deve”, até) ser feita com linguagem simples, entendida facilmente por todos os envolvidos no processo. Se feita corretamente, qualquer um pode (teoricamente) escrever testes – como o gerente de projetos, o P.O., o especialista do domínio, etc.

Parte-se do critério de aceitação para criar a seguinte “fórmula”:

Pré-condição + Ação = Resultado Esperado

Ou, em sintaxe Gherkin:

Given – When – Then (Dado que – Quando – Então)

O BDD começou com um framework em Java (o JBehave) e depois foi adaptado a outras linguagens conforme se atestava sua eficiência. A lista de frameworks inclui RBehave, RSpec, Spory Runner e Cucumber (um dos mais famosos).

Práticas do BDD

Existem diversas práticas que fazem parte da abordagem. Eis algumas das mais importantes:

• Envolver, de alguma forma, todas as partes interessadas no processo (Outside-In Development);
• Usar linguagem comum, “universal”, para descrever o comportamento da aplicação;
• Automatizar exemplos para fornecer um feedback rápido e testes de regressão;
• Usar “should” (“deveria”) ao descrever o comportamento do software, ajudando a esclarecer responsabilidades e permitindo o questionamento de funcionalidades;
• Usar dublês de teste (mocks, fakes, dummies, stubs, spies) para ajudar na colaboração entre módulos e códigos ainda não escritos.

Uma das consequências da aplicação bem sucedida do BDD é que os desenvolvedores podem focar nas razões pelas quais o código deve ser criado, mantendo um necessário contato com a realidade prática – quem é da área sabe como pode ser complicado fazer isso quando se passa horas diante de linhas de código.

É possível, com isso, avaliar se a nova funcionalidade é coerente com o resto do projeto, e comparar com o que já está escrito ou planejado.

Naturalmente, a abordagem casa excepcionalmente bem com as user stories, embora não se limite a elas.

Usemos como exemplo um e-commerce de videogames antigos.

User story:

• Para: que eu possa pesquisar consoles e jogos clássicos
• Sendo: um visitante que acessou o catálogo
• Posso: buscar produtos pelo título

Cenário “Produto Disponível”, para BDD:

• Dado que: estou na loja virtual
• E: preencho o campo de busca com “Mega Drive”
• Quando: clico em “Buscar”
• Então: devo ver o produto no catálogo

Vejamos uma maneira mais detalhada de escrever o cenário Produto Disponível:

• Dado que: o cliente acessou “Super Nintendo” no catálogo
• E: recebi uma ação para adicionar ao carrinho
• Quando: eu faço uma requisição posterior para o serviço Add To Cart
• Então: o código de resposta deve ser “200”
• E: um novo carrinho deve ser criado com o ID do cliente
• E: o código do produto é inserido no carrinho do cliente

Pode-se considerar que, mesmo mais detalhado, o cenário continua fácil de compreender. Essa simplicidade típica do BDD também fica mais clara quando se pensa nos ciclos tradicionais:

Esquema Tradicional de Desenvolvimento

Modelo enxuto

Mas e os testes? No BDD, eles estão presentes em todos os ciclos de desenvolvimento, alocados de maneira estratégica para garantir a qualidade sem comprometer a agilidade nas entregas.

Acompanhe a Prime Control para receber mais conteúdos como este!