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

TDD: a ordem importa — teste antes do código

Gabarito: Errado (E). O TDD (Test-Driven Development) é uma técnica de desenvolvimento em que o teste é escrito antes do código de produção, e não depois — o enunciado inverte a ordem do ciclo Red-Green-Refactor, que é a essência da prática. A afirmação de que a especificação de teste é escrita "logo após o código" contraria o princípio fundamental do TDD, que é guiar o desenvolvimento pelos testes.

O TDD, ou Desenvolvimento Orientado a Testes, é uma técnica de desenvolvimento de software que inverte a lógica tradicional: em vez de escrever o código e depois testá-lo, o desenvolvedor escreve primeiro um teste automatizado que define o comportamento desejado da nova funcionalidade. Esse teste, naturalmente, falha (etapa Red), pois o código que o faria passar ainda não existe. Em seguida, escreve-se o código mínimo necessário para que o teste passe (etapa Green). Por fim, o código é refatorado para melhorar sua estrutura sem alterar seu comportamento (etapa Refactor). Esse ciclo é conhecido como Red-Green-Refactor e é a espinha dorsal do TDD.

A lógica por trás dessa ordem é dupla. Primeiro, escrever o teste antes força o desenvolvedor a pensar no comportamento esperado da funcionalidade antes de implementá-la, o que melhora o design e a clareza dos requisitos. Segundo, o teste que falha inicialmente comprova que ele é eficaz — se o teste passasse antes de o código existir, seria um sinal de que ele não está testando nada de útil. O TDD está fortemente associado ao Extreme Programming (XP), metodologia ágil que valoriza testes contínuos e a integração do teste ao processo de produção de código.

Um exemplo prático: imagine que você precisa implementar uma função que soma dois números. No TDD, você escreveria primeiro um teste como assert(soma(2, 3) == 5). Esse teste falharia porque a função soma ainda não existe. Então, você implementaria a função de forma minimalista — apenas para fazer o teste passar. Depois, refatoraria o código se necessário. O teste é o guia, não o verificador posterior.

A pegadinha desta questão é sutil: ela mistura conceitos. O TDD não é um tipo de teste unitário — é uma técnica de desenvolvimento que utiliza testes (geralmente unitários) como ferramenta. E a ordem é invertida: o teste vem antes do código, não depois. A banca explora exatamente essa confusão entre "testar depois de codificar" (abordagem tradicional) e "codificar guiado por testes" (TDD).

Guarde a fronteira: no TDD, o teste é escrito antes do código de produção, e o ciclo é Red-Green-Refactor. É exatamente nessa inversão que a questão se apoia.

Item — ❌ ERRADO

A afirmação está incorreta por dois motivos principais:

1. A ordem está invertida: no TDD, a especificação de teste é escrita antes do código, não "logo após". O ciclo é: escrever o teste (que falha) → escrever o código mínimo para passar → refatorar.

1. TDD não é um tipo de teste unitário: é uma técnica/filosofia de desenvolvimento que se vale de testes automatizados (frequentemente unitários) para guiar a implementação. Não é uma classificação de teste, mas uma abordagem de desenvolvimento.

O enunciado descreve, na verdade, a abordagem tradicional de desenvolvimento, em que o código é escrito primeiro e depois se escrevem testes para validá-lo — exatamente o oposto do que o TDD propõe.

Gabarito: Errado (E).