Questão de Engenharia de Software — TDD e BDD (Test-Driven Development e Behavior Driven Development) — FGV 2024

TDD (Test Driven Development) — Ciclo Red-Green-Refactor

Gabarito: letra D. O TDD é uma técnica de desenvolvimento guiado por testes em que o ciclo se inicia com a escrita de um teste automatizado que falha (Red), segue com a codificação mínima para fazê-lo passar (Green) e finaliza com a refatoração do código para eliminar redundâncias (Refactor) — exatamente o que a alternativa D descreve. Essa é a essência do método criado por Kent Beck, que inverte a ordem tradicional: o teste vem antes do código de produção.

O TDD (Desenvolvimento Orientado por Testes) é uma prática que integra o teste ao processo de desenvolvimento, em vez de deixá-lo apenas para o final. A ideia central é simples: antes de escrever qualquer código de produção, o desenvolvedor escreve um teste automatizado que define o comportamento esperado de uma nova funcionalidade. Como a funcionalidade ainda não existe, esse teste inicialmente falha — e é exatamente essa falha que orienta o desenvolvimento. O ciclo é conhecido como Red-Green-Refactor:

1. Red (Vermelho): escrever um teste automatizado que falha, pois a funcionalidade ainda não foi implementada.

2. Green (Verde): escrever o código mínimo necessário para fazer o teste passar.

3. Refactor (Refatoração): melhorar a estrutura do código, eliminando redundâncias e duplicações, sem alterar seu comportamento.

Esse ciclo curto se repete para cada nova funcionalidade, garantindo que o código seja constantemente validado e que a qualidade seja mantida ao longo de todo o desenvolvimento. O TDD está diretamente relacionado aos conceitos de verificação e validação: a verificação responde "estamos construindo o produto corretamente?" e a validação responde "estamos construindo o produto certo?". No TDD, o teste automatizado atua como uma ferramenta de verificação contínua, enquanto a refatoração assegura que o código permaneça limpo e sustentável.

Uma distinção importante é entre TDD e BDD (Behavior Driven Development). Enquanto o TDD foca no teste como guia para o desenvolvimento, o BDD é uma evolução que foca no comportamento do sistema, utilizando uma linguagem ubíqua e cenários escritos em linguagem natural (como Gherkin, com a estrutura Dado-Quando-Então). No TDD, o desenvolvedor escreve os testes técnicos; no BDD, os cenários são mais próximos da linguagem do negócio e frequentemente envolvem a colaboração entre desenvolvedores, testadores e stakeholders.

A pegadinha que a banca explora nesta questão é a confusão entre TDD e BDD, além da inversão da ordem do ciclo. Muitos candidatos confundem o TDD com uma abordagem orientada a comportamentos (que é o BDD) ou acreditam que o teste é escrito durante ou após o código. A alternativa D é a única que descreve corretamente o ciclo completo: teste → código → refatoração. Guarde essa sequência: é exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Afirma que o TDD é "desenvolvimento orientado para os comportamentos". Essa é a definição de BDD (Behavior Driven Development), não de TDD. O TDD é orientado a testes, não a comportamentos. Além disso, a alternativa mistura os papéis: no TDD, o desenvolvedor escreve os testes, mas a validação não é feita "de forma que eles funcionem" — o teste deve falhar inicialmente para orientar o desenvolvimento.

Alternativa B — ❌ Incorreta

Diz que o TDD é "desenvolvimento orientado para os testes, sendo atribuição do programador escrever como o problema deve se comportar". A primeira parte está correta (é orientado a testes), mas a segunda parte descreve o BDD, onde o foco é o comportamento do sistema. No TDD, o programador escreve testes técnicos que definem o comportamento esperado do código, mas a descrição de "como o problema deve se comportar" em linguagem natural é característica do BDD.

Alternativa C — ❌ Incorreta

Afirma que o TDD "se refere a escrever um teste automatizado durante o desenvolvimento do código de fato". Isso contraria a essência do TDD: o teste deve ser escrito antes do código de produção, não durante. A ordem é fundamental — o teste é escrito primeiro, falha, e então o código é desenvolvido para fazê-lo passar.

Alternativa D — ✅ Correta ⟵ GABARITO

Descreve corretamente o ciclo do TDD: inicia com a criação de um teste (Red), segue com a codificação para passar no teste (Green) e finaliza com a eliminação de redundâncias por meio da refatoração (Refactor). Essa é a sequência exata do ciclo Red-Green-Refactor, que é a base do TDD.

Alternativa E — ❌ Incorreta

Descreve uma abordagem em que "são intercalados testes, elicitação de requisitos e desenvolvimento de código, tendo os testes embutidos em um programa separado que os executa e invoca o sistema que está sendo testado". Isso não corresponde ao TDD. No TDD, o ciclo é focado em teste → código → refatoração, sem a intercalação com elicitação de requisitos. A descrição de "testes embutidos em um programa separado" pode até lembrar frameworks de teste, mas não é a definição do TDD.

Gabarito: letra D