Questão de Engenharia de Software — Teste de Software — FCC 2018
Engenharia de Software›Teste de Software
Código
fc049154
Banca
FCC
Órgão
SEFAZ-SC
Ano
2018
Cargo
Auditor-Fiscal da Receita Estadual - Tecnologia da Informação (Prova 3)
O Test-Driven Development (TDD) é uma abordagem para o desenvolvimento de programas em que se intercalam testes e desenvolvimento de código. As etapas do processo fundamental de TDD são mostradas abaixo em ordem alfabética:I. Escrever um teste para a funcionalidade identificada e implementá-lo como um teste automatizado.II. Executar o teste, junto com os demais testes já implementados, sem implementar a nova funcionalidade no código.III. Identificar e implementar uma outra funcionalidade, após todos os testes serem executados com sucesso.IV. Identificar uma nova funcionalidade pequena para ser incrementada com poucas linhas em um código.V. Implementar a nova funcionalidade no código e reexecutar o teste.VI. Refatorar o código com melhorias incrementais até que o teste execute sem erros.VII. Revisar a funcionalidade e o teste, caso o código execute sem falhar.Considerando o item IV a primeira etapa e o item III a última etapa, a sequência intermediária correta das etapas do processo é:
AI − II − VII − V e VI.
BI − V − II − VII e VI.
CI − VI − V − VII e II.
DV − I − II − VII e VI.
EV − I − VI − VII e II.
Revelar gabarito e comentário▾
GabaritoA — I − II − VII − V e VI.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Test-Driven Development (TDD) – Sequência das Etapas
Gabarito: letra A. Segundo o ciclo TDD, após identificar uma nova funcionalidade (IV), escreve-se o teste automatizado (I), executa-se o teste para verificar sua falha (II), revisa-se o teste e a funcionalidade para garantir que o teste é válido (VII), implementa-se o código para passar no teste (V) e, por fim, refatora-se o código (VI). A última etapa (III) é identificar outra funcionalidade. Essa sequência (IV → I → II → VII → V → VI → III) corresponde exatamente à alternativa A.
A banca cobra o entendimento do fluxo do TDD: o teste deve ser escrito e executado antes da implementação, e a revisão do teste ocorre justamente após sua execução, antes de codificar. As demais alternativas invertem etapas ou colocam a implementação antes do teste, o que viola o princípio fundamental do TDD.
1Identificar funcionalidade
2Escrever teste automatizado
3Executar teste (falha esperada)
4Revisar funcionalidade e teste
5Implementar código e reexecutar
6Refatorar até passar
7Identificar nova funcionalidade
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
A sequência IV (identificar funcionalidade) → I (escrever teste) → II (executar teste sem implementação) → VII (revisar funcionalidade e teste, caso o código execute sem falhar – aqui a revisão é feita após o teste falhar, garantindo que o teste é adequado) → V (implementar funcionalidade e reexecutar teste) → VI (refatorar até passar) → III (identificar outra funcionalidade). É a ordem canônica do TDD.
Alternativa B — ❌ Incorreta
Inverte as etapas: coloca a implementação (V) antes da execução do teste sem código (II). No TDD, primeiro escreve-se o teste, executa-o para que falhe, e só então se implementa.
Alternativa C — ❌ Incorreta
Coloca a refatoração (VI) antes da implementação (V) e da execução do teste (II), o que não faz sentido: a refatoração só ocorre após o teste passar.
Alternativa D — ❌ Incorreta
Inicia com a implementação (V) em vez do teste (I), contrariando a essência do TDD.
Alternativa E — ❌ Incorreta
Também começa pela implementação (V) e coloca a refatoração (VI) antes da execução do teste (II), invertendo a ordem lógica.
NÃO CAIA NESSA!
A banca tenta confundir o candidato colocando a implementação (V) como primeira etapa ou inserindo a refatoração (VI) antes da execução do teste. Lembre-se: no TDD, o teste sempre vem antes do código de produção. A sequência correta é: escrever teste → executar (falha) → revisar (se necessário) → implementar → refatorar.