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!