Questão de Tecnologia da Informação · CESGRANRIO CAIXA 1/2021/NM (nº 53)

TDD (Desenvolvimento Dirigido por Testes) é um ciclo curto: primeiro você escreve um teste que falha (porque a funcionalidade ainda não existe), depois escreve o mínimo de código para passar nesse teste e, por fim, refatora. O teste é o "rascunho" do comportamento esperado, não uma consequência do código.

• (A) Incorreta: TDD não é sobre "congelar" código aprovado; é sobre modificar o código constantemente em pequenos passos, guiado por testes que falham e depois passam.
• (B) Incorreta: Escrever testes depois do código é o oposto do TDD. Aqui o teste vira apenas uma "rede de segurança" tardia, não um guia de design.
• (C) Incorreta: Histórias de usuário são descrições de funcionalidade em linguagem de negócio; TDD usa testes automatizados (unitários, de integração) escritos em linguagem de programação, não histórias em si.
• (D) Correta: O coração do TDD é projetar os casos de teste antes de criar o código fonte. O teste define a especificação executável: você pensa no comportamento desejado, escreve o teste, vê ele falhar (red), implementa o código mínimo (green) e refatora.
• (E) Incorreta: Repetir todos os testes a cada modificação é uma prática de regressão (comum em CI/CD), mas não é a característica definidora do TDD. No TDD, a repetição é contínua e incremental, mas o que o define é a ordem (teste primeiro).

Armadilha da banca na letra E: Ela parece "óbvia" porque todo mundo sabe que se deve rodar testes após mudanças. Mas isso é verificação, não desenvolvimento dirigido por testes. A banca quer que você perceba que TDD é uma estratégia de escrita de código, não uma rotina de execução de testes. Quem marca E confunde "testar depois" com "testar antes".