-
Certo. Galera, você tem um código que funciona, mas deseja melhorar a eficiência dele. Recomenda-se que se faça uma série de testes sólidos para verificar as funcionalidades antes de refatorar o código. Dizer que SEMPRE se deve começar com testes soa estranho e cabe, sim, recurso, visto que – muitas vezes – os testes já foram feitos; mas estou com a impressão de que o CESPE não vai aceitar :(
http://www.estrategiaconcursos.com.br/blog/stj2015-analista-comentarios-da-prova-de-engenharia-de-software-e-desenvolvimento/
-
Pois é. O SEMPRE é que pegou. Pq o sólido conjunto de testes deve existir independentemente da refatoração, por isso acho meio forçada essa afirmação
-
Questão mal elaborada, pois a refatoração é independente de testes. E o comando da questão não faz referência a abordagem TDD.
MAS.... no TDD temos o seguinte ciclo:
1. Adicione um teste - " deve sempre começar com a criação de um sólido conjunto de testes para o trecho de código a ser trabalhado."
2. Execute todos os testes e veja se algum deles falha
3. Escrever código
4. Execute os testes automatizados e veja-os executarem com sucesso
5. Refatorar código - "O processo de refatoração"
6. Repita tudo
-
Talvez a questão tenha tentado se referir ao TDD e seu ciclo RGR (Red - Green - Refactor)
Red - Crie testes que deverão falhar para as novas funcionalidades
Green - Escreva código para passar no teste
Refactor - Elimine redundâncias, elementos de projeto não utilizados, algoritmos ineficientes ou desnecessários, estruturas de dados mal construídas ou inapropriadas, ou qualquer outra falha de projeto que possa ser corrigida para produzir um projeto melhor.
-
Um tipo de questão que atrapalha quem sabe o conceito.