Durante o processo de construção de software, a metodologia de Desenvolvimento Orientado a Testes é muito aplicada. A ordem utilizada na prática do TDD é
- A)escrever a funcionalidade após escrever os testes unitários e, por fim, refatorar o código implementado.
Correta, pois traduz a sequência do TDD: escrever os testes unitários, implementar a funcionalidade e depois refatorar.
- B)escrever os testes unitários após escrever a funcionalidade e, por fim, refatorar o código implementado.
Errada, porque inverte a lógica do TDD ao mandar escrever a funcionalidade antes dos testes.
- C)escrever a funcionalidade após refatorar o código implementado e por fim escrever os testes unitários.
Errada, porque coloca a refatoração antes da escrita dos testes e ainda desorganiza a sequência do ciclo.
- D)escrever os testes unitários após escrever a funcionalidade e, por fim, escrever os testes de integração.
Errada, porque o TDD não é definido por testes de integração, e sim pelo ciclo com testes unitários antes da implementação.
- E)escrever os testes de integração após escrever a funcionalidade e, por fim, refatorar o código.
Errada, porque mistura testes de integração com TDD e também coloca a refatoração fora da ordem correta.
Gabarito: A
No TDD, a lógica é quase um ritual em três passos: primeiro você escreve o teste antes do código, depois implementa a menor funcionalidade necessária para fazer o teste passar e, por fim, refatora para melhorar a qualidade interna sem mudar o comportamento. Esse ciclo é conhecido como "Red, Green, Refactor": teste falha, teste passa, refatoração. A ideia central do Desenvolvimento Orientado a Testes é obrigar o código a nascer já guiado por requisitos verificáveis. Assim, os testes não viram um detalhe deixado para o final, mas o ponto de partida da implementação. Isso ajuda a reduzir retrabalho, melhora a cobertura e deixa o código mais confiável para mudanças futuras. Por isso, o gabarito A está correto: ele descreve exatamente a prática do TDD, em que você escreve os testes unitários antes da funcionalidade, implementa a funcionalidade em seguida e, depois, refatora o que foi construído. Esse é o fluxo clássico adotado na doutrina de engenharia de software e na prática profissional. As demais alternativas trocam a ordem dos passos ou misturam TDD com testes de integração. Em prova, a banca costuma cobrar essa sequência em sua forma mais conhecida, então vale guardar a tríade como se fosse receita de bolo: teste, código, refatoração.