Behavior Driven Development

Embora o BDD (Behavior-Driven Development) seja frequentemente associado aos testes de software, não é uma técnica de teste.

Em essência, o BDD é uma abordagem colaborativa de desenvolvimento que procura alinhar todas as partes interessadas sobre o comportamento esperado do sistema, utilizando uma linguagem comum, muitas vezes estruturada no formato "Dado... Quando... Então..." (Gherkin).

Alguns pontos que podem ajudar a entender por que o BDD não é uma técnica de testes:

1. Objetivo de comunicação: o BDD foi criado para facilitar a comunicação entre equipas técnicas e não-técnicas, pois ao transformar os requisitos em descrições claras do comportamento do sistema, facilita o entendimento entre programadores, testers, product owners e outros stakeholders. A intenção é que todos compreendam o comportamento esperado, sem se aprofundarem nos detalhes técnicos de código ou nos testes em si.

2. Definição de requisitos e comportamento: o BDD concentra-se na definição de comportamento do sistema do ponto de vista do utilizador final, o que antecede a fase de teste. Ou seja, é usado para definir o que o sistema deve fazer (requisitos) e não apenas como testar se o sistema está a funcionar corretamente.

3. Processo de desenvolvimento guiado pelo comportamento: Em vez de testar funcionalidades prontas, o BDD orienta o desenvolvimento. Os cenários de BDD são usados para construir as funcionalidades de acordo com os comportamentos desejados. Assim, os cenários servem também como documentação viva do sistema e como um guia para o desenvolvimento.

4. Cenários de negócio ao invés de Cenários de teste: Os cenários escritos no BDD não são apenas casos de teste, mas exemplos do comportamento esperado da aplicação em diferentes situações. Esses exemplos são compreendidos por todos na equipa, ajudando a alinhar o que deve ser entregue ao cliente e a criar uma visão compartilhada de sucesso.

5. Integração com o Desenvolvimento Ágil: Em metodologias ágeis, o BDD alia-se ao desenvolvimento incremental, permitindo que as equipas construam funcionalidades com base no comportamento esperado em pequenos ciclos. Isso orienta o desenvolvimento com foco na experiência e nos resultados de negócio, que vão além de simplesmente "passar nos testes".

---

O BDD e o Gherkin têm uma relação direta, dado que o Gherkin é a linguagem usada para escrever os cenários de teste recorrendo à abordagem BDD. Mas vamos tentar entender a relação:

1) Gherkin como linguagem para especificar cenários de BDD

No BDD, os cenários de teste são definidos numa linguagem comum para descrever como a aplicação se deve comportar. O Gherkin é essa linguagem! Padronizada e estruturada de maneira que pessoas técnicas e não técnicas possam entender facilmente, com comandos simples como "Dado... Quando... Então...", o Gherkin permite a criação de cenários claros e objetivos que expressam os requisitos de negócios e expectativas.

2) Facilidade de comunicação e colaboração

A utilização do Gherkin na abordagem BDD torna mais fácil para todas as partes interessadas (stakeholders, programadores, QAs) a discussão e o entendimento do comportamento do sistema. Como é uma linguagem natural que segue um formato específico, o Gherkin elimina ambiguidades e ajuda a equipa a garantir que o desenvolvimento esteja alinhado com as necessidades reais do utilizador.

3) Automação de cenários BDD

Ferramentas de automação como Cucumber, SpecFlow, Behave, entre outras, são compatíveis com a linguagem Gherkin, e isso permite que os cenários escritos em abordagem BDD sejam convertidos em testes automatizados. Cada linha de um cenário em Gherkin pode ser mapeada para um script automatizado, possibilitando que os testes verifiquem o comportamento da aplicação conforme definido nos cenários de BDD.

4) Padronização e Documentação Viva

Como o Gherkin segue uma estrutura padronizada, os cenários escritos nesta linguagem servem como documentação viva do sistema. Isso significa que os cenários não apenas definem como o sistema deve funcionar, como também permanecem atualizados com o código, o que facilita a manutenção e entendimento contínuo da aplicação.

Exemplo Prático de Cenário em BDD com Gherkin

Aqui está um exemplo simples de um cenário BDD escrito em Gherkin para uma funcionalidade de login. Relembrando, o BDD é a abordagem de definir como a aplicação deve se comportar para cumprir um objetivo de negócio (permitir o login) e o Gherkin é a linguagem usada para especificar esse comportamento numa estrutura que a equipa pode seguir e que futuramente pode ser automatizada.

Funcionalidade: Login de Utilizador

  Cenário: Login com credenciais válidas
    Dado que o utilizador está na página de login
    Quando o utilizador insere o username "utilizador1" e password "senha123"
    E clica no botão de login
    Então o utilizador é redirecionado para a página inicial
    E uma mensagem de boas-vindas é exibida

Em suma, a relação entre o BDD e o Gherkin é de interdependência.

BDD define a filosofia de focar no comportamento e nos objetivos de negócio, enquanto Gherkin fornece a linguagem para expressar esses comportamentos em cenários de fácil compreensão e automação.

Assim, o Gherkin é fundamental para implementar o BDD, transformando os requisitos de negócios em especificações que se alinham com o desenvolvimento e testes de software.