Fui um desenvolvedor que não sabia nada de testes. Talvez muitos desenvolvedores ainda não saibam exatamente o que testar.
Esse é o problema original que BDD veio resolver.
Mas vejo muitas equipes e empresas confundindo o propósito do BDD.
Neste artigo, tentarei esclarecer sobre BDD e dar dicas de como utilizar esta ideia na sua equipe.
Introdução rápida#
BDD ou Behaviour Driven Development tem como objetivo facilitar a compreensão sobre testes para desenvolvedores:
Programadores queriam saber por onde começar, o que testar e o que não testar, quanto testar de uma vez, como chamar seus testes e como entender por que um teste falha. - Dan North
Para isso, o foco deve mudar para:
- Especificação, não testes
- Cenário, não caso de testes
Ou seja, devemos pensar quais são as especificações ou comportamentos esperados de um sistema para um usuário final, assim como os cenários que esse usuário pode enfrentar.
Por exemplo, vamos supor que estamos começando um projeto onde o usuário, pessoa física, pode ter uma conta corrente
Então, uma especificação e os cenários para este exemplo poderia ser:
📜 Especificação: Conta Corrente de uma Pessoa Física#
🌟 Cenário: Abrir uma conta corrente
Given:
Issao deseja abrir uma conta corrente.
When:
Quando Issao preenche o formulário de abertura de conta com suas informações pessoais e documentos
And:
Envia o formulário para análise
Then:
A conta corrente deve ser criada com sucesso
And:
Issao deve receber uma confirmação por e-mail
🌟 Cenário: Sacar dinheiro da conta corrente
Given:
Issao possui uma conta corrente com saldo de R$ 200,00
When:
Quando Issao realiza um saque de R$ 100,00
Then:
O saldo da conta corrento do Issao deve ser R$ 100,00
E assim por diante.
Estas especificações e cenários de exemplos ajudam os desenvolvedores e a equipe a escrever testes melhores.
📝 Nota
Usei Gherkin como exemplo para representar os cenários, mas não é a peça mais importante! É mais importante você e sua equipe terem um template que sempre lembre de três partes para descrever um cenário:
- Dados (Given)
- Ação (When)
- Resultado esperado (Then)
Quais são os dados que eu preciso para executar minha ação?
Que ação devo executar que resolver a necessidade do usuário final?
Qual o resultado esperado da minha ação?
Dicas fundamentais para prática do BDD#
Compartilho quatro dicas rápidas para começar a praticar o BDD!
Não descreva “como” seu sistema funciona#
Já vi muitos exemplos assim:
🌟 Cenário: Selecionar uma música do playlist
Dado que o usuário quer ouvir "Green Day - Time of Your Life"
Quando o usuário clica no botão "Minha Playlist" e vai clicando no botão "Próximo" até chegar na música
E clica no botão "Play"
Então deve tocar a música
Esse é um exemplo ruim de especificação.
Se o nosso sistema mudar um pouco o workflow, a especificação já está errada.
Descreva “o que” o seu sistema faz#
Melhorando o exemplo anterior, ficaria assim:
🌟 Cenário: Selecionar uma música do playlist
Dado que o usuário quer ouvir "Green Day - Time of Your Life"
Quando o usuário seleciona a playlist
E encontra a música para tocar
Então deve tocar a música
Neste exemplo, o foco está mais claro. Devemos ter alguma solução que encontra a música fácil dentro de uma playlist.
Não estou testando a implementação, mas estou garantindo o comportamento esperado.
Escreva a especificação e os cenários antes do código#
É fundamental essa dica. É o coração do BDD.
BDD serve para orientar os desenvolvedores sobre testes.
Se estas especificações estão surgindo depois do código, pode ter certeza que vai falhar a longo prazo.
O processo deve suportar a implementação do BDD#
BDD é uma prática que envolve todos:
- Desenvolvedores
- Q.A.
- Gerentes
- Líderes
Para facilitar a adoção do BDD, um processo bem definido que suporta estas práticas é essencial.
Um exemplo de como poderia ser um processo que suporta o BDD:
- Devemos entender o desejo do cliente
- Transformar o desejo do cliente em história (Story)
- Gerar exemplos a partir da história
- Definir critério de aceitação a partir dos exemplos
- Capturar critério de aceitação como especificações executáveis (testes automatizados)
- Criar a feature a partir das especificações executáveis
Para mais dicas, recomendo a leitura do artigo Introducing BDD do criador Dan North.
Conclusão#
Quando começamos a utilizar o BDD em uma equipe, começamos a pensar de fora para dentro.
Precisamos entender a necessidade do cliente, pensar em uma solução que satisfaz a necessidade do cliente para chegar nas especificações e cenários e finalmente implementá-los.
É uma das maneiras de orientar o design do seu software/aplicação!
BDD não é só sobre testes!
É sobre como colaborar, através de especificações claras e cenários bem detalhados, para entregar a melhor solução possível para o usuário final.
Se você tiver dúvidas, sugestões ou até correções, sinta-se à vontade para comentar ou falar diretamente comigo!
🥒🥒 Até o próximo artigo! 🥒🥒