Questão de Engenharia de Software — Teste de Software — INSTITUTO AOCP 2025

TDD e BDD: desenvolvimento guiado por testes e por comportamento

Gabarito: letra C — sequência F – V – V – V – V. A primeira afirmativa é falsa porque, no TDD, os testes são escritos antes da implementação do código (ciclo Red-Green-Refactor), e não depois; as demais afirmativas (II, III, IV e V) descrevem corretamente o BDD, o formato Given-When-Then e os objetivos e limitações de ambas as abordagens.

O TDD (Test-Driven Development) é uma técnica de desenvolvimento de software que inverte a ordem tradicional: em vez de codificar primeiro e testar depois, o desenvolvedor escreve um teste automatizado para uma funcionalidade que ainda não existe, executa esse teste e o vê falhar (etapa vermelha), escreve o código mínimo necessário para fazê-lo passar (etapa verde) e, por fim, refatora o código para melhorar sua qualidade sem alterar o comportamento (etapa de refatoração). Esse ciclo curto e repetitivo é conhecido como Red-Green-Refactor e é a essência do TDD. O objetivo não é apenas testar, mas guiar o design do código: como o teste é escrito primeiro, o desenvolvedor é forçado a pensar na interface e no comportamento esperado antes da implementação, o que tende a gerar código mais simples, modular e testável.

O BDD (Behavior-Driven Development) é uma evolução do TDD que amplia seu escopo ao focar no comportamento do sistema, descrito em uma linguagem natural e compreensível por todos os envolvidos — desenvolvedores, testadores, analistas de negócio e clientes. Essa linguagem ubíqua, geralmente o Gherkin, utiliza o formato Given-When-Then (Dado-Quando-Então) para estruturar cenários de teste que descrevem funcionalidades de forma clara e colaborativa. Enquanto o TDD se concentra na unidade de código e na sua testabilidade, o BDD se preocupa com a clareza dos requisitos e a comunicação entre os times técnicos e não técnicos, garantindo que todos compartilhem o mesmo entendimento do que deve ser construído.

Ambas as abordagens melhoram a automação de testes, mas não eliminam a necessidade de testes manuais, especialmente em áreas que envolvem interação do usuário, usabilidade e avaliações subjetivas. A automação é excelente para verificar regras de negócio e comportamentos previsíveis, mas não substitui o olhar humano para aspectos como experiência do usuário, design visual e cenários complexos de interação.

A pegadinha desta questão está na primeira afirmativa: ela inverte a ordem do TDD, afirmando que os testes são escritos após a implementação. Essa é uma confusão clássica com o modelo tradicional de desenvolvimento, onde os testes são criados depois do código. No TDD, a ordem é exatamente o oposto: o teste vem primeiro, falha, e só então o código é escrito para fazê-lo passar. Guarde essa distinção: TDD = teste antes do código; modelo tradicional = código antes do teste.

Afirmativa I — ❌ Falsa

A afirmativa diz que "no TDD, os testes são escritos após a implementação do código". Isso é exatamente o oposto do que o TDD prega. No TDD, o teste é escrito antes do código de produção, seguindo o ciclo Red-Green-Refactor: primeiro escreve-se um teste que falha (vermelho), depois implementa-se o código mínimo para fazê-lo passar (verde) e, por fim, refatora-se (azul). O objetivo é que o teste guie o desenvolvimento, garantindo que o código seja testável e atenda exatamente ao comportamento esperado. A banca inverteu a ordem para confundir o candidato.

Afirmativa II — ✅ Verdadeira

A afirmativa está correta. O BDD amplia o conceito do TDD ao enfatizar a descrição do comportamento do sistema em linguagem natural, permitindo maior colaboração entre desenvolvedores, testadores e analistas de negócio. Essa é a essência do BDD: usar uma linguagem ubíqua (como o Gherkin) para que todos os envolvidos compreendam e validem o comportamento esperado do sistema, promovendo a comunicação e o alinhamento entre os times técnicos e não técnicos.

Afirmativa III — ✅ Verdadeira

A afirmativa está correta. O formato Given-When-Then (Dado-Quando-Então) é uma estrutura utilizada no BDD para descrever cenários de teste de forma compreensível para todos os envolvidos no projeto. Cada cenário começa com um contexto (Given/Dado), seguido de uma ação (When/Quando) e termina com um resultado esperado (Then/Então). Essa estrutura torna os cenários legíveis e colaborativos, facilitando a validação dos requisitos por parte dos stakeholders.

Afirmativa IV — ✅ Verdadeira

A afirmativa está correta. O TDD tem como principal objetivo garantir que o código seja testável e modular, pois o teste escrito antes força o desenvolvedor a pensar na interface e no design do código. Já o BDD visa melhorar a clareza dos requisitos e a comunicação entre times técnicos e não técnicos, focando no comportamento do sistema em linguagem natural. São objetivos complementares: o TDD melhora a qualidade interna do código, enquanto o BDD melhora o entendimento e a validação dos requisitos.

Afirmativa V — ✅ Verdadeira

A afirmativa está correta. TDD e BDD melhoram a automação de testes, mas não substituem totalmente os testes manuais, especialmente para áreas que envolvem interação do usuário e avaliações subjetivas. A automação é eficiente para verificar regras de negócio e comportamentos previsíveis, mas não consegue avaliar aspectos como usabilidade, experiência do usuário, design visual e cenários complexos de interação, que exigem o julgamento humano.

Conclusão: Corretas as afirmativas II, III, IV e V; incorreta apenas a afirmativa I. Portanto, a sequência correta é F – V – V – V – V, correspondente à letra C.

Gabarito: letra C