🚀 Capítulo 11: BDD (Behavior-Driven Development) (Tema: Star Trek)
NOTE
Este capítulo utiliza a temática de Star Trek para explicar o BDD. O Tradutor Universal da Enterprise permite que raças diferentes se entendam; o BDD permite que clientes e programadores falem a mesma língua!
1. 🎯 Objetivo da Aula
Compreender o conceito de Desenvolvimento Orientado por Comportamento (BDD) e aprender a escrever cenários de teste usando a linguagem Gherkin (Dado, Quando, Então).
2. 🏢 O Cenário Prático (Seu Desafio)
A tripulação da Enterprise encontra novas espécies na galáxia.
- Os alienígenas falam sobre “Negócios” (O que eles querem que o sistema faça).
- Os engenheiros da nave falam sobre “Código” (Como fazer o sistema funcionar).
Se eles não usarem o Tradutor Universal, haverá guerra (bugs)! O BDD é esse tradutor. Ele usa uma linguagem simples que qualquer ser humano (ou alienígena) consegue ler, descrevendo o comportamento esperado do sistema antes mesmo dele ser programado! Seu desafio é escrever uma mensagem no tradutor!
3. 🧠 Fundamentos: A Teoria Traduzida
O BDD (Behavior-Driven Development) é uma prática que une o Cliente (Dono do produto), o Desenvolvedor e o QA (Testador) para definir como o sistema deve se comportar através de exemplos em linguagem natural.
🥒 A Linguagem Gherkin (Dado, Quando, Então):
Para escrever os cenários de BDD, usamos uma estrutura padrão chamada Gherkin:
- Dado (Given): O contexto inicial, o estado do sistema.
- Quando (When): A ação que o usuário realiza.
- Então (Then): O resultado esperado, a consequência da ação.
4. 📖 Exemplo Guiado: Dobra Espacial (JS)
Vamos escrever o comportamento de acionamento da velocidade de dobra da Enterprise:
Cenário: Acionar velocidade de dobra com sucesso
Dado que a Enterprise está em órbita e com os motores carregados
Quando o Capitão disser "Engajar"
Então a nave deve entrar em velocidade de dobra espacial
E o painel deve mostrar "Velocidade Máxima Ativada"O incrível do BDD é que esse texto acima é o próprio teste! Existem ferramentas (como o Cucumber) que leem esse texto em português e executam o teste no código!
5. 🛠️ Prática Obrigatória 1: Escrevendo em Gherkin
Imagine que você está testando o sistema de teletransporte da nave. Escreva o cenário em Gherkin preenchendo as lacunas:
- Dado que o Capitão Kirk está na plataforma de teletransporte…
- Quando o operador puxar a alavanca de envio…
- Então [Qual o resultado esperado para o Capitão?]
- E [O que deve acontecer com a plataforma?].
6. 🛠️ Prática Obrigatória 2: A Tríade do BDD
O BDD diz que um cenário só é bom se for discutido pela “Tríade”: Cliente, Desenvolvedor e Testador. Por que é importante ter essas 3 visões? O que acontece se o programador escrever o cenário sozinho sem falar com o cliente?
7. 📤 Instruções de Entrega (GitHub Desktop + Microsoft Teams)
- Faça o Commit: No GitHub Desktop, digite a mensagem (ex:
Finaliza Capítulo 11 Qualidade) e clique em Commit to main. - Envie para a Nuvem (Push): Clique em Push origin.
8. 📂 Estrutura de Pastas
mod_11_qualidade_e_testes_de_software/
├── capitulos/
│ ├── capitulo_11_bdd.md
│ └── codigos/
│ └── cap11/
│ └── teletransporte.feature9. 💡 Checkpoint de Lógica
O BDD foca no comportamento e no valor de negócio, não nos detalhes técnicos. Evite escrever coisas como “Quando eu clicar no botão azul de ID btn32”. Escreva “Quando eu confirmar a operação”.
10. 🔥 Desafio de Fixação
Pesquise sobre a ferramenta Cucumber e como ela integra arquivos .feature (Gherkin) com linguagens como Java, JavaScript ou Python.
🔑 Gabarito de Código/Fórmulas
Gabarito da Prática 1:
- Dado que o Capitão Kirk está na plataforma de teletransporte.
- Quando o operador puxar a alavanca de envio.
- Então o Capitão Kirk deve desaparecer da plataforma e aparecer no planeta.
- E as luzes da plataforma devem piscar em azul.