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

TDD (Test-Driven Development) e o ciclo Red-Green-Refactor

❌ ERRADO. O item está incorreto porque inverte o significado das etapas do ciclo TDD: na fase vermelha (red) o desenvolvedor escreve o teste que ainda vai falhar (pois o código de produção não existe), e não o código de produção. A descrição apresentada no enunciado — "escrever o código de produção necessário para que o teste, criado na fase anterior, passe a funcionar" — corresponde, na verdade, à etapa verde (green), que é a segunda do ciclo.

O TDD (Desenvolvimento Orientado a Testes) é uma técnica de desenvolvimento de software que inverte a ordem tradicional: em vez de escrever o código e depois testá-lo, o desenvolvedor escreve primeiro o teste automatizado que define o comportamento desejado da nova funcionalidade, e só então implementa o código mínimo necessário para fazê-lo passar. Essa inversão é a essência da técnica — o teste funciona como uma especificação executável do que o código deve fazer.

O ciclo completo, conhecido como Red-Green-Refactor, funciona assim:

1. Red (Vermelho): escreve-se um teste automatizado para uma funcionalidade que ainda não existe. Ao executar esse teste, ele falha (fica "vermelho"), o que comprova que o teste realmente testa algo novo e que a funcionalidade ainda não foi implementada.

2. Green (Verde): escreve-se o código de produção mínimo (a forma mais simples possível) apenas para fazer o teste passar (ficar "verde"). Nesta etapa, não se busca qualidade ou elegância — apenas fazer o teste passar.

3. Refactor (Refatorar): com o teste passando, o código é refatorado para melhorar sua estrutura interna, eliminar duplicações e atender a padrões de qualidade, sempre garantindo que os testes continuem passando após cada alteração.

A lógica por trás dessa ordem é dupla. Primeiro, escrever o teste antes do código força o desenvolvedor a pensar no comportamento esperado antes da implementação, o que tende a gerar um design mais simples e focado. Segundo, ver o teste falhar antes de ver passar garante que o teste é eficaz — se o teste passasse antes de existir o código, ele não estaria testando nada de útil.

Um exemplo concreto: suponha que se queira implementar uma função que soma dois números. No TDD, o desenvolvedor primeiro escreve um teste como assert(soma(2, 3) == 5). Ao executar, o teste falha porque a função soma nem existe (etapa vermelha). Depois, implementa-se a função de forma minimalista — def soma(a, b): return a + b — e o teste passa (etapa verde). Por fim, refatora-se o código se necessário, mantendo o teste verde.

A pegadinha desta questão é exatamente a inversão das etapas: o enunciado atribui à fase vermelha o que é próprio da fase verde. É uma armadilha clássica de banca, que troca o sujeito da ação — na fase vermelha escreve-se o teste; na fase verde escreve-se o código de produção. O candidato que memorizou apenas os nomes das fases (red-green-refactor) sem entender o que cada uma faz cai facilmente nessa inversão.

Guarde a fronteira: vermelho = escrever o teste que falha; verde = escrever o código que faz o teste passar; refatorar = melhorar o código sem mudar o comportamento. É exatamente nessa distinção que o item se separa entre certo e errado.

Item — ❌ Errado

O erro está na definição da etapa vermelha. O enunciado afirma que "vermelho é a etapa que consiste em escrever o código de produção necessário para que o teste, criado na fase anterior, passe a funcionar corretamente". Isso está invertido:

• Na etapa vermelha, escreve-se o teste (que ainda não existe código de produção) e ele falha.

• Na etapa verde, escreve-se o código de produção mínimo para fazer o teste passar.

Portanto, a descrição dada no item corresponde à etapa verde, não à vermelha. A ordem correta do ciclo é: escrever o teste (red) → escrever o código mínimo (green) → refatorar (refactor). O item erra ao atribuir à primeira fase a ação que pertence à segunda.

Gabarito: letra E (Errado).