Questão de Engenharia de Software — Geral — INSTITUTO AOCP 2026

TDD (Test-Driven Development): o ciclo vermelho-verde-refatoração

Gabarito: letra C. O TDD é uma prática de desenvolvimento em que o teste é escrito antes do código de produção: escreve-se um teste que falha (vermelho), implementa-se o código mínimo para fazê-lo passar (verde) e, por fim, refatora-se o código mantendo os testes aprovados. Essa é a essência do ciclo descrito na alternativa C, que espelha fielmente o fluxo canônico do TDD.

O TDD (Test-Driven Development, ou Desenvolvimento Orientado a Testes) é uma técnica de programação que inverte a ordem tradicional de desenvolvimento: em vez de codificar primeiro e testar depois, o desenvolvedor escreve primeiro um teste automatizado para uma funcionalidade que ainda não existe. Esse teste, ao ser executado, deve falhar — é a fase "vermelha" do ciclo. A falha é proposital e necessária: ela prova que o teste realmente exercita o comportamento desejado e que o código ainda não implementa aquela regra. Em seguida, escreve-se o código mínimo e suficiente para fazer o teste passar — a fase "verde". Por fim, com o teste já passando, realiza-se a refatoração: melhora-se a estrutura interna do código (legibilidade, eliminação de duplicação, aderência a padrões) sem alterar seu comportamento externo, e os testes são executados novamente para garantir que nada quebrou. Esse ciclo se repete em incrementos pequenos, uma funcionalidade (ou subfunção) de cada vez.

A lógica por trás dessa ordem é dupla. Primeiro, o teste escrito antes funciona como uma especificação executável: ele define o comportamento esperado de forma concreta e verificável, guiando a implementação. Segundo, a refatoração contínua, amparada pela rede de testes, permite melhorar o código com segurança, pois qualquer regressão é imediatamente detectada. O TDD também gera um conjunto de testes de regressão que cresce a cada iteração e é executado a cada mudança, garantindo que o novo código não introduza efeitos colaterais no que já foi implementado.

Na prática, imagine que a equipe do IFCE precise implementar o cálculo de carga horária docente. Pelo TDD, o analista começaria escrevendo um teste que verifica, por exemplo, se a função calcularCargaHoraria(disciplinas) retorna a soma correta das horas. Esse teste falharia porque a função ainda não existe. Então, ele implementaria a função de forma minimalista — talvez apenas somando as horas — até o teste passar. Depois, refatoraria o código para tratar casos como disciplinas com carga variável ou sobreposição de horários, sempre rodando os testes para confirmar que o comportamento continua correto. Esse fluxo contrasta diretamente com a abordagem tradicional de "implementar tudo e testar no final", que é justamente o que o TDD busca evitar.

A pegadinha que a banca explora nesta questão é a inversão da ordem entre teste e código. Alternativas que descrevem testes escritos após a codificação, ou testes manuais no final, ou código e teste em paralelo sem ordem definida, todas contradizem o princípio fundamental do TDD: o teste vem antes e guia a implementação. Guarde o ciclo vermelho → verde → refatorar como o critério decisivo: é exatamente nele que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Descreve o fluxo oposto ao TDD: implementar toda a funcionalidade, testar manualmente ao final e só então automatizar. Isso é a abordagem tradicional de desenvolvimento, em que o teste é uma etapa posterior à codificação. No TDD, o teste automatizado é escrito antes do código, não depois, e não há "testes manuais ao final" como etapa central do ciclo.

Alternativa B — ❌ Incorreta

Afirma que os testes são escritos ao término da codificação para validar requisitos já implementados. Isso inverte a ordem do TDD: no TDD, o teste é escrito antes do código de produção, e o código é escrito para fazer o teste passar. Escrever testes depois da implementação é a prática tradicional de teste, não o TDD.

Alternativa C — ✅ Correta ⟵ GABARITO

Descreve com precisão o ciclo do TDD: escrever um teste que falha (vermelho), implementar o código mínimo para fazê-lo passar (verde) e refatorar mantendo os testes aprovados. Essa é a sequência canônica do TDD, conforme descrita por Kent Beck e amplamente difundida na literatura de engenharia de software. A alternativa captura os três passos essenciais na ordem correta.

Alternativa D — ❌ Incorreta

Propõe criar testes apenas para cenários de exceção, deixando os fluxos principais para validação em produção. Isso é um erro grave: no TDD, os testes devem cobrir todos os comportamentos esperados da funcionalidade, incluindo os fluxos principais de negócio, não apenas as exceções. Além disso, validar fluxos principais em produção é uma prática arriscada e contrária ao espírito do TDD, que busca feedback rápido e seguro por meio de testes automatizados.

Alternativa E — ❌ Incorreta

Sugere desenvolver código e testes em paralelo, sem ordem definida. Isso contradiz o princípio central do TDD, que estabelece uma ordem rígida: primeiro o teste, depois o código. O TDD não é uma prática "paralela" ou "sem ordem" — é uma prática sequencial e disciplinada, em que o teste sempre precede a implementação.

Gabarito: letra C