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

Desenvolvimento Guiado por Testes (TDD)

Gabarito: letra B. No ciclo TDD, após escrever um teste para uma funcionalidade ainda não implementada, o próximo passo é executar esse teste e verificar se ele falha — é a chamada "etapa vermelha" do ciclo. Essa falha é proposital e essencial: ela comprova que o teste realmente testa algo que ainda não existe, garantindo que, quando o código for implementado, o teste passe por mérito próprio e não por ser ineficaz.

O Desenvolvimento Guiado por Testes (TDD, do inglês Test-Driven Development) é uma técnica de programação que inverte a ordem tradicional: em vez de implementar a funcionalidade e depois testá-la, o desenvolvedor primeiro escreve o teste e só então implementa o código mínimo necessário para fazê-lo passar. Essa abordagem, popularizada por Kent Beck, é frequentemente descrita como um ciclo de três etapas, conhecidas pelas cores de um semáforo:

1. Etapa Vermelha (Red): escrever um teste automatizado para a funcionalidade desejada e executá-lo, confirmando que ele falha (porque o código ainda não existe).

2. Etapa Verde (Green): implementar o código da forma mais simples e minimalista possível, apenas para fazer o teste passar.

3. Etapa de Refatoração (Refactor): melhorar a estrutura e a qualidade interna do código, sem alterar seu comportamento externo, e rodar os testes novamente para garantir que continuam passando.

A lógica por trás da etapa vermelha é dupla. Primeiro, ela valida o próprio teste: se um teste recém-escrito já passa sem que a funcionalidade exista, ou o teste é ineficaz (não testa o que deveria), ou a funcionalidade já estava implementada no sistema. Segundo, ela cria um "contrato" claro: o teste define o comportamento esperado, e o código só será aceito quando cumprir esse contrato. É exatamente essa verificação de falha que a alternativa B descreve.

Na prática, imagine que o engenheiro precisa implementar uma função calcularDesconto(valor). No TDD, ele primeiro escreve um teste que chama essa função com um valor e espera um resultado específico. Ao rodar o teste, ele falha porque a função nem existe — e isso é o esperado. Só então ele implementa a função de forma mínima para satisfazer o teste. Depois, refatora o código para melhorar sua qualidade, sempre rodando os testes novamente.

A pegadinha que a banca explora nesta questão é a inversão da ordem natural do desenvolvimento: muitos candidatos, acostumados ao fluxo tradicional (implementar → testar), escolhem a alternativa E, que sugere rodar o teste e garantir que ele passe logo após escrevê-lo. Mas isso contraria a essência do TDD, que exige a falha inicial como prova de que o teste é válido. Guarde o ciclo vermelho → verde → refatoração: é exatamente nessa sequência que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Esta alternativa inverte a ordem do TDD ao sugerir implementar a funcionalidade antes de verificar o teste. No TDD, o teste é escrito antes do código, e a implementação só ocorre após a confirmação de que o teste falha. Além disso, escrever "mais testes para outras funcionalidades" antes de implementar a atual quebra o ciclo incremental da técnica.

Alternativa B — ✅ Correta ⟵ GABARITO

Esta é a essência da etapa vermelha do TDD. Após escrever o teste para uma funcionalidade inexistente, o próximo passo é executá-lo e confirmar que ele falha. Essa falha é intencional e serve para provar que o teste tem poder de detecção — se ele passasse de imediato, não estaria testando nada de novo. O material de apoio confirma: "Esse conjunto de testes deve ser executado e falhar. Isso é feito para mostrar que os testes efetivamente têm algum poder de teste e não terão sucesso a não ser que o código específico seja desenvolvido."

Alternativa C — ❌ Incorreta

Ignorar os testes e focar apenas na implementação é o oposto absoluto do TDD. A técnica coloca os testes como o centro do processo de desenvolvimento, não como um acessório descartável. Essa alternativa representa uma visão tradicional e equivocada do papel dos testes.

Alternativa D — ❌ Incorreta

Escrever todos os testes do sistema antes de qualquer implementação não é o que o TDD preconiza. O TDD trabalha de forma incremental: escreve-se um teste, vê-se falhar, implementa-se o mínimo, vê-se passar, refatora-se, e então parte-se para a próxima funcionalidade. Escrever todos os testes de uma vez contraria o ciclo curto e iterativo da técnica.

Alternativa E — ❌ Incorreta

Esta é a pegadinha clássica. Rodar o teste e garantir que ele passe logo após escrevê-lo ignora a etapa vermelha. No TDD, o teste deve falhar primeiro para ser considerado válido. Se ele já passa de imediato, não há como saber se o teste é eficaz ou se a funcionalidade já existia. A alternativa descreve o comportamento esperado na etapa verde, mas não como próximo passo imediato após escrever o teste.

Gabarito: letra B