Behavior Driven Development ou BDD (Desenvolvimento Guiado por Comportamento)

Você trabalhou duro. Teclou em seu teclado até que tudo estivesse bem. Você se inclina para trás em sua cadeira, sorrindo. Sim, você está feliz com o resultado.

Alguns dias depois, seus ombros estão flácidos. O cliente não estava contente. Não é o que eles desejavam.

Que pena.

Mas anime-se, há uma resposta: Behavior Driven Development ou BDD para abreviar.

Continue lendo para saber o que é, como beneficia desenvolvedores, testadores e empresas, e o que implica em praticá-lo. Vamos começar com o que é.

O que é Behavior Driven Development in Agile em Agile?

Src: flatstack.com

A definição mais sucinta de Behavior Driven Development com a qual me deparei é esta:

BDD é um processo projetado para auxiliar a gestão e a entrega de projetos de desenvolvimento de software, melhorando a comunicação entre engenheiros e profissionais de negócios. Ao fazer isso, o BDD garante que todos os projetos de desenvolvimento permaneçam focados na entrega do que o negócio realmente precisa, atendendo a todas as exigências do usuário.

O Behaviour Driven Development Não se Trata de Testes

Sim, praticar BDD significa que você vai especificar e executar testes. Mas testar não é o objetivo.

Porque, assim como seu companheiro TDD (Test Driven Development), o BDD não se trata de testes. Trata-se de atingir as metas comerciais e os resultados do cliente no nível da aplicação. Assim como a definição tão claramente afirma.

Qual é a Relação entre BDD e Agile?

Bem, com BDD você garante um software funcional sobre uma documentação abrangente no nível da aplicação e ainda obtém essa documentação.

Além disso, o Agile tem fortes raízes em eXtreme Programming. E Dan North – que originou o BDD – é um entusiasta de eXtreme Programming há muito tempo.

Três Amigos como Ideia Central do Behavior Driven Development

A ideia central no behaviour driven development é que nenhuma pessoa ou campo tem a resposta completa para qualquer coisa.

Você precisa de Três Amigos: profissionais de negócios, desenvolvedores e testadores para obter boas respostas.

Além disso, você precisa que eles colaborem. Porque é o ir e vir entre pessoas com diferentes estilos cognitivos e diferentes perspectivas e origens, que produz mágica. Mágica que lhe traz soluções melhores, mais simples e mais valiosas.

O que cada um dos Três Amigos traz para a mesa:

• Os profissionais de negócios trazem as necessidades da empresa e as exigências dos clientes. Eles estão na melhor posição para decidir o quanto uma história é desejável em comparação com outras.
• Os desenvolvedores são os especialistas em software e oportunidades tecnológicas. Eles estão na melhor posição para avaliar quão fácil ou difícil será implementar uma história.
• Os testadores são indispensáveis para sua capacidade de, quase instintivamente, detectar obstáculos e lacunas. Eles identificarão os casos de ponta antes que eles causem problemas mais adiante.

Quais São os Benefícios do BDD?

Quando você adota o Behavior Driven Development, você pode esperar estes benefícios:

• Colocando os objetivos comerciais e as exigências do cliente na frente e no centro.
• Diretrizes para estruturar a conversa entre os Três Amigos. Isto os torna mais efetivos e produtivos.
• Definição de critérios de aceitação antes do início do desenvolvimento.
• Evitar esforços em características que não contribuem para as metas comerciais.
• Evitar interpretações errôneas que levem a refazer o trabalho mais adiante.
• Linguagem ubíqua. Uma linguagem específica de domínio que é usada em todos os lugares do software.
• Especificações que pessoas não-técnicas podem facilmente entender.
• Especificações executáveis
  • Testes de aceitação automatizados que fornecem feedback rápido para manter a implementação nos trilhos.
  • Especificações vivas que nunca estão desatualizadas.
  • Documentação técnica e do usuário final gerada automaticamente, também nunca desatualizada..

As Fases do Behavior Driven Development

No BDD você passa por três fases para cada história que deseja implementar.

As três fases são:

• Descoberta. Aqui é onde você explora uma história em uma conversa estruturada. Ela tem dois objetivos. Um é garantir que a história contribua para os resultados comerciais. Por exemplo, com o método dos Cinco Porquês. O outro objetivo é assegurar a compreensão compartilhada do que é necessário, delineando exemplos concretos de cenários específicos.
• Formulação. É aqui que você reformula (formula) os exemplos em uma linguagem estruturada e os transforma em especificações executáveis.

Estes seguem o padrão dado-quando-então:

o cenário (determinado) — o estado inicial, por exemplo, “o usuário está logado”,

o evento (quando) — o que acontece, por exemplo “o usuário pressiona o botão de logout”, e

o resultado (então) — a resposta esperada, por exemplo, “a página de login é mostrada”.

• Automação. Aqui é onde você transforma as especificações executáveis em testes de aceitação automatizados. Usando ferramentas como o Cucumber, é uma questão de conectar a ferramenta ao software.

Software operacional: Os testes de aceitação guiam seu trabalho de implementação do software.

Um Exemplo BDD 

Vamos passar pelas fases de Descoberta e Formulação para lhe dar um exemplo.

Título: Bloqueando outros usuários.

Narrativa: Como membro, quero bloquear usuários, para que eles não me incomodem mais.

Descoberta

A história parece simples o suficiente, mas as perguntas surgem assim que você começa a pensar bem nela:

• Que resultado comercial é servido?
• O que significa bloquear? O que isso implica? O que você precisa para que isso aconteça?
• O que significa “não me incomodar mais”? O que isso parece? O que precisa acontecer ou não acontecer?

A lista continua e continua.

Depois de conversar com o cliente, acontece que eles simplesmente não querem ver as atualizações de um usuário bloqueado em seu feed de atividades.

Portanto, fica com: como membro, quero silenciar os usuários, para que meu feed de atividades não mostre suas atualizações. Uma questão muito mais simples de resolver e muito menor no escopo.

Ainda assim, mesmo agora, não está totalmente claro o que precisa ser feito e o que não precisa ser feito. É hora de esclarecer com exemplos a partir da perspectiva do usuário.

• Quando eu silencio outro usuário, e esse usuário envia uma atualização, não quero vê-la em meu feed.
• Quando eu silenciar outro usuário, e eu rolar de volta no meu feed, eu não quero ver nenhuma atualização desse usuário.

Formulação

Agora você escreve cada exemplo na notação estruturada que pode ser lida e executada por software.

• Dado que eu silenciei |algum usuário|, quando visito meu feed de atividades, então o feed não deve conter atualizações de |algum usuário|.
• Dado que eu silenciei |algum usuário|, quando |algum usuário| envia uma atualização, ela não deve ser adicionada às minhas notificações.

Como Não Tirar o Máximo de BDD

Erros comuns em Behavior Driven Development são:

• Deixando de fora os testers nas fases de Descoberta e Formulação.
• Assumindo que escrever os exemplos é o que conta.
• Deixando de lado a fase de Descoberta porque você acha que já sabe o que precisa fazer.

O que é Behavior Driven Testing?

Behavior Driven Testing (BDT) é um processo menos conhecido que leva ao teste de aceitação automatizado. Assim como o BDD, ele promove a colaboração entre pessoas técnicas e não técnicas. E também usa uma linguagem natural formalizada para escrever testes que podem ser facilmente revisados e verificados por profissionais de negócios.

Mas o BDT se concentra mais no que os usuários fazem com o software. Ao invés dos critérios de aceitação que verificam a implementação da lógica empresarial.

Qual é a Diferença entre TDD e BDD?

Behavior Driven Development e Test Driven Development são similares e diferentes ao mesmo tempo.

• Ambos empregam abordagens de teste primeiro, mas não são sobre testes.
  • O BDD visa melhorar a colaboração e a comunicação entre os desenvolvedores, testadores e profissionais de negócios. Para que o software atenda tanto aos objetivos comerciais quanto às exigências dos clientes.
  • TDD é sobre design e especificações em nível de código.
• O BDD atua no nível de aplicação e requisitos. O TDD concentra-se no nível do código que implementa esses requisitos.
• O TDD é, ou pode ser usado como a fase “Faça testes passarem” do BDD.
• No TDD você pode, mas não precisa, usar técnicas de BDD até o menor nível de abstração.
• O BDD não tem uma fase de refatoração como o TDD.

Comece a Criar Software Útil que os Clientes Desejam

A imagem acima ilustra como é difícil para um cliente descrever o que ele quer, e como fica deformado à medida que avança pelo caminho. É um clichê por uma razão, e um com uma longa história.

Mas usando o Behavior Driven Development, você pode fazer disso uma coisa do passado.

Sim, pode ser difícil parar e pensar, “perder” tempo tendo as conversas que o ajudarão a fazer isso.

Mas, vale a pena. Você vai criar um software útil que os clientes realmente querem, e você o fará sem ter que refazer, reparar ou retrabalhar o que já fez antes.