Questão de Engenharia de Software — Teste de Software — FGV 2024
Engenharia de Software›Teste de Software
Código
fg075553
Banca
FGV
Órgão
AL-SC
Ano
2024
Nível
Superior
Cargo
Analista Legislativo III - Analista de Sistemas
A prática de Test Driven Development (TDD, ou Desenvolvimento Orientado por Testes) se relaciona com o conceito de verificação e validação e se baseia em um ciclo para garantir a qualidade do código.Entre as características do TDD, é correto o que se afirma em
Atrata-se de desenvolvimento orientado para os comportamentos, sendo o desenvolvedor responsável por escrever os testes e validá-los de forma que eles funcionem.
Btrata-se de desenvolvimento orientado para os testes, sendo atribuição do programador escrever como o problema deve se comportar.
Cna prática, se refere a escrever um teste automatizado durante o desenvolvimento do código de fato.
Do ciclo do TDD se inicia com a criação de um teste, para auxiliar a codificação, segue com a realização da codificação para passar no teste, e finaliza com a eliminação das redundâncias, ao se refatorar o código.
Eno desenvolvimento de programas são intercalados testes, elicitação de requisitos e desenvolvimento de código, tendo os testes embutidos em um programa separado que os executa e invoca o sistema que está sendo testado.
Revelar gabarito e comentário▾
GabaritoD — o ciclo do TDD se inicia com a criação de um teste, para auxiliar a codificação, segue com a realização da codificação para passar no teste, e finaliza com a eliminação das redundâncias, ao se refatorar o código.
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)
Gabarito: letra D. O TDD é uma prática de desenvolvimento que segue um ciclo de três etapas: escrever um teste automatizado que falha, codificar a funcionalidade mínima para passar no teste e, por fim, refatorar o código para eliminar redundâncias e melhorar a qualidade. Essa descrição corresponde exatamente à alternativa D.
A banca cobra o conhecimento do ciclo clássico do TDD, conforme descrito no material de apoio: primeiro o teste, depois o código, depois a refatoração.
1Escrever teste que falha
2Codificar mínimo para passar
3Refatorar (eliminar redundâncias)
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Define o TDD como "desenvolvimento orientado para os comportamentos". Essa é a definição de BDD (Behavior-Driven Development), não de TDD. No TDD, o foco são os testes unitários, não o comportamento do sistema como um todo.
Alternativa B — ❌ Incorreta
"Desenvolvimento orientado para os testes" é uma aproximação, mas a frase "escrever como o problema deve se comportar" é imprecisa e remete à especificação de comportamento, e não ao ciclo de escrever teste-falha-código-refatoração.
Alternativa C — ❌ Incorreta
Afirma que o teste automatizado é escrito "durante o desenvolvimento do código". No TDD, o teste é escrito antes do código, não durante.
Alternativa D — ✅ Correta ⟵ GABARITO
Descreve fielmente o ciclo do TDD: criar teste → codificar para passar no teste → refatorar (eliminar redundâncias). Essa é a sequência consagrada (red-green-refactor).
Alternativa E — ❌ Incorreta
Menciona "intercalados testes, elicitação de requisitos e desenvolvimento de código" e um programa separado que executa os testes. Isso não é específico do TDD; o TDD se concentra no ciclo teste-código-refatoração, sem necessariamente envolver elicitação de requisitos ou um executor externo.
PEGA ESSA DICA!
Lembre-se do mantra "Red-Green-Refactor": escreva um teste que falhe (Red), faça-o passar com o mínimo de código (Green) e depois melhore o código (Refactor). Essa é a essência do TDD.