Questão de Engenharia de Software — Desenvolvimento de Software — FGV 2024
Engenharia de Software›Desenvolvimento de Software
Código
fg077380
Banca
FGV
Órgão
CVM
Ano
2024
Nível
Superior
Cargo
Analista - Perfil 8 - TI / Sistemas e Desenvolvimento - Tarde
Maurício é o líder técnico do Time de Tecnologia da Informação (TTI) de uma organização que está iniciando o uso do estilo de Desenvolvimento Orientado a Testes (TDD).De forma a nivelar o conhecimento e obedecendo ao estilo TDD, Maurício orientou que os(as):
Atestes comecem por uma operação complexa;
Bcasos de teste menores dispensem a escrita de asserções;
Ctestes de recursos complexos, como acesso a dados, sejam especificados como testes de integração;
Dcoleções de objetos sejam implementadas sem coleções e, após testadas, sejam reescritas para funcionar com coleções;
Eos desenvolvedores registrem nos comentários da ferramenta de versionamento os testes que foram criados, já que a execução de um teste afeta a execução de outro.
Revelar gabarito e comentário▾
GabaritoD — coleções de objetos sejam implementadas sem coleções e, após testadas, sejam reescritas para funcionar com coleções;
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”.
Desenvolvimento Orientado a Testes (TDD)
Gabarito: letra D. No TDD, o ciclo é: escrever um teste que falhe, implementar o código mínimo para passar e, em seguida, refatorar. Uma prática comum é começar com a implementação mais simples possível (ex.: sem coleções, usando um array fixo) e, após validar o teste, reescrever o código usando coleções, melhorando a qualidade sem quebrar os testes já aprovados. Essa abordagem é coerente com o princípio de refatoração do TDD.
1Escrever teste que falha
2Implementar código mínimo
3Teste passa?
4[+] Refatorar código
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
O TDD orienta começar com o teste mais simples, não com uma operação complexa. Isso garante que o desenvolvedor entenda gradualmente o comportamento e mantenha o foco em pequenos incrementos.
Alternativa B — ❌ Incorreta
Todo caso de teste, mesmo os menores, deve conter asserções. Sem asserções, não é possível verificar se o código se comporta conforme o esperado, violando a essência do TDD.
Alternativa C — ❌ Incorreta
No TDD, os testes são preferencialmente de unidade, rápidos e isolados. Recursos complexos como acesso a dados devem ser isolados com mocks ou stubs, não transformados em testes de integração, que são mais lentos e frágeis para o ciclo iterativo do TDD.
Alternativa D — ✅ Correta ⟵ GABARITO
Esta alternativa descreve a prática de "fake it" e refatoração: primeiro implementa-se a solução mais simples (sem coleções, por exemplo), faz-se o teste passar e, em seguida, reescreve-se o código usando coleções (refatoração). Isso garante que os testes sejam executados contra uma implementação funcional antes de otimizá-la.
Alternativa E — ❌ Incorreta
Testes automatizados devem ser independentes entre si; a execução de um não deve afetar a de outro. Comentários em ferramentas de versionamento sobre testes não fazem parte da disciplina TDD e não resolvem a dependência de testes.