BDD: o que é, cenários de comportamento e frameworks

O que é BDD?

Behavior-Driven Development é uma evolução do TDD proposta por Dan North em 2006 como resposta ao problema da formulação de testes. No TDD, o desenvolvedor escreve um teste, mas a pergunta “o que testar exatamente?” permanece em aberto. O BDD resolve esse problema deslocando o foco de testar código para descrever o comportamento do sistema da perspectiva do usuário.

A inovação chave do BDD é uma linguagem comum para todos os participantes do projeto. Desenvolvedores, testadores, analistas e clientes discutem cenários em uma linguagem unificada que simultaneamente serve como um teste executável. Isso elimina o problema clássico do “telefone sem fio” onde os requisitos perdem significado ao passar do analista para o desenvolvedor.

História do surgimento do BDD

Dan North formulou o BDD em 2006 em seu artigo “Introducing BDD” no blog ThinkCode. Ele notou que os nomes dos testes no TDD são frequentemente formulados em termos de implementação (“testAddUser”) em vez de termos de comportamento (“o usuário deve poder se registrar com email”). O BDD substituiu a palavra “test” por “should” e “assert” por “expect”, deslocando o foco para o valor do usuário.

BDD como prática de comunicação

De acordo com um estudo da Universidade de Cambridge (2021), projetos que usam cenários BDD na comunicação com o cliente reduzem erros de requisitos em 35% em comparação com especificações tradicionais em documentos de texto. Cenários executáveis não permitem formulações ambíguas — cada Given-When-Then ou passa ou falha.

Linguagem Gherkin e sintaxe

Gherkin é uma linguagem de domínio específico usada pelos frameworks Cucumber e SpecFlow para descrever cenários de comportamento. Gherkin usa indentação e palavras-chave para estruturar cenários, permanecendo legível para pessoas sem formação técnica.

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

Palavras-chave do Gherkin

Gherkin define várias palavras-chave básicas. Feature descreve a funcionalidade, Scenario descreve um cenário específico, Given descreve as pré-condições, When descreve a ação, Then descreve o resultado esperado. Além disso, And e But são usados para combinar múltiplas condições.

Estrutura do arquivo .feature

Arquivos Gherkin têm a extensão .feature e são armazenados no diretório src/test/resources/features/ em projetos Android. Cada arquivo começa com uma descrição de Feature, seguida por um ou mais Scenarios. Para parametrização, usa-se Scenario Outline com tabelas de Examples — isso permite executar o mesmo cenário com dados diferentes.

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

Formato Given-When-Then

Given-When-Then é um padrão estrutural para descrever cenários, adotado pelo BDD do domain-driven design. Cada cenário consiste em três partes: pré-condições, ação e resultado esperado. Este formato corresponde naturalmente ao Arrange-Act-Assert dos testes unitários, mas usa linguagem amigável para negócios.

Given: contexto

O bloco Given descreve o estado do sistema antes do início do cenário: quais dados existem, quais componentes estão ativos, em que modo o aplicativo opera. No contexto móvel, isso pode ser “o usuário está logado”, “o carrinho não está vazio” ou “o dispositivo está em modo offline”.

When: ação

O bloco When descreve um evento iniciado pelo usuário ou sistema: pressionar um botão, receber uma notificação push, resposta do servidor. Em aplicativos móveis, isso geralmente corresponde a chamar um método do ViewModel ou clicar em um elemento de interface.

Then: resultado

O bloco Then descreve a mudança de estado esperada: mudança de tela, chamada de API, atualização de banco de dados. As verificações no Then devem ser mensuráveis e inequívocas — elas se tornam assertions no código executável.

BDD e TDD: comparação de abordagens

BDD e TDD são frequentemente confundidos, embora sejam diferentes níveis de disciplina. TDD é uma técnica de design no nível de código: “como escrever a implementação”. BDD é uma técnica de especificação no nível de requisitos: “o que o sistema deve fazer”.

Complementaridade no projeto

Os melhores projetos móveis usam TDD no nível de classes individuais (camada de domínio) e BDD no nível de cenários (camada de funcionalidades). Isso fornece dupla cobertura: TDD garante a correção da implementação, BDD garante a correção do entendimento dos requisitos. O Google em sua prática interna usa uma combinação de TDD e BDD para aplicativos Android, conforme indicado na documentação do Android Testing (2024).

Ferramentas BDD para desenvolvimento móvel

O ecossistema BDD inclui frameworks para todas as plataformas e linguagens populares de desenvolvimento móvel. A escolha da ferramenta depende da pilha de tecnologia e do nível de automação.

Cucumber para Android

Cucumber é o framework BDD mais popular, trabalhando com cenários Gherkin. Para projetos Android, usa-se a biblioteca io.cucumber:cucumber-android, que se integra com as ferramentas de teste de interface Espresso e Compose Test. O Cucumber suporta Kotlin e Java, tornando-o uma escolha universal para estúdios que usam ambas as linguagens.

SpecFlow para Xamarin

SpecFlow é um framework BDD para o ecossistema .NET, usado em projetos Xamarin.Forms e .NET MAUI. O SpecFlow se integra com NUnit e xUnit, e seus step definitions são escritos em C#. Para projetos móveis, o SpecFlow permite reutilizar cenários entre versões Android e iOS do aplicativo em uma base de código compartilhada.

Quick/Nimble para iOS

Para desenvolvimento iOS em Swift, existem os frameworks BDD Quick e Nimble. O Quick fornece um DSL para descrever cenários no estilo describe/it, e o Nimble fornece matchers com sintaxe legível. Embora esses frameworks não usem Gherkin diretamente, eles implementam o princípio BDD: descrever comportamento em uma linguagem compreensível para toda a equipe.

Exemplos de cenários BDD e código

Vamos ver um exemplo completo de BDD em um projeto Android: um cenário de finalização de pedido. Primeiro escrevemos um cenário Gherkin, depois os step definitions em Kotlin.

Princípio de funcionamento do BDD: three amigos

A metodologia BDD é baseada na reunião dos three amigos — três papéis: desenvolvedor, testador e analista. Eles escrevem cenários juntos antes do início do desenvolvimento, estabelecendo um entendimento compartilhado dos requisitos. Se um dos três participantes não entender o cenário, significa que o requisito foi formulado de forma ambígua. Esta prática é descrita no livro “Discovery: Explore Behaviour Using Examples” (Gáspár & North, 2021) e é uma parte obrigatória do processo BDD em equipes maduras.

Cenário Gherkin de finalização de pedido

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Step definitions em Kotlin

Step definitions são código que conecta cenários Gherkin com a implementação de teste. Cada passo é um método com uma anotação correspondente a uma palavra-chave do Gherkin.

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

Integração com Cucumber Android

Para executar testes BDD em um projeto Android, usa-se CucumberAndroidJUnitRunner. Ele escaneia arquivos .feature nos recursos, encontra os step definitions correspondentes por expressões regulares e executa os cenários como testes instrumentados normais. Os resultados são formatados em um relatório HTML compreensível para o cliente.

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

Desafios da implementação de BDD em projetos móveis

A implementação de BDD no desenvolvimento móvel traz várias dificuldades práticas. A compreensão desses problemas ajuda as equipes a evitar frustrações e construir um processo BDD sustentável.

Manutenção de arquivos .feature

O principal problema é a dessincronização entre cenários Gherkin e código de produção. Se os desenvolvedores mudam APIs sem atualizar os step definitions, os arquivos .feature deixam de corresponder à implementação. A solução é executar testes BDD no pipeline CI/CD e exigir status verde para merge requests. A prática de “BDD como mecanismo de gate” é descrita na documentação do Cucumber (2024) e é um padrão da indústria.

Desempenho dos testes BDD

Cenários BDD no Cucumber são executados como testes instrumentados em um dispositivo Android ou emulador. Isso é 10–50 vezes mais lento que testes unitários comuns na JVM. Um único teste de aceitação pode levar de 20 a 30 minutos para um aplicativo Android grande. Recomenda-se executar testes BDD em um job CI separado à noite, enquanto os testes unitários são executados a cada push. Essa estratégia equilibra velocidade de feedback e cobertura de cenários.

Treinamento da equipe em Gherkin

A transição para BDD requer treinamento não apenas de desenvolvedores, mas também de analistas e testadores. Gherkin é uma linguagem simples, mas escrever bons cenários requer prática. Erros típicos de iniciantes: cenários muito longos (mais de 10 passos), misturar Given-When-Then, usar termos técnicos em cenários de negócios. De acordo com a BDD Academy (2024), as equipes precisam em média de 4 a 6 sprints para alcançar maturidade na escrita de cenários BDD.