1
resposta

Refatoração do método LocalizaVeiculoNoPatioComIdTicket

Na aula deu para entender perfeitamente a refatoração feita e a nova necessidade do dono do produto, o problema não foi a compreensão da "Lógica de negócio".

Mas veja bem, o próprio nome do teste diz "LocalizaVeiculo", a partir do momento que o objeto do veículo não é mais retornado na pesquisa e sim o ticket de entrada dele, perdemos o sentido de nomes claros e descritivos.

O método deveria ser a partir de agora algo como: "LocalizaTicketDoVeiculoComBaseNoIdTicket", já que não conseguimos mais encontrar o veículo e sim somente seu ticket.

Em um dos momentos da aula o Assert ainda comparava a placa do veículo com o objeto encontrado, a partir do momento que o Assert comparou o texto do ticket, o nome do teste parou de fazer sentido.

Se a funcionalidade de localizar um veículo com base na placa ainda fosse utilizada em algum outro local do sistema mais testes teriam dado errado e todos teriam que ser refatorados, inclusive em lugares que a busca do veículo fizesse parte do Arrange/Act para um Assert. A não ser que essa busca fosse totalmente extinta pela solicitação do dono do produto, não seria o ideal criar um novo método de busca e um novo teste?

1 resposta

Olá, Lucas.

Tudo bem?

Entendo perfeitamente o seu ponto, com a clareza e a consistência dos nomes dos métodos e testes. Você está absolutamente correto em apontar que a mudança na lógica de negócios, de localizar um veículo para localizar um ticket, deveria refletir nos nomes dos métodos e testes.

Sobre a sua pergunta "não seria o ideal criar um novo método de busca e um novo teste?", a resposta depende muito do contexto do projeto. Se a funcionalidade de localizar um veículo com base na placa ainda é necessária em algum lugar do sistema, então sim, seria ideal manter o método original e criar um novo método para localizar o ticket. No entanto, se a funcionalidade original não é mais necessária (como parece ser o caso aqui), então refatorar o método existente para atender à nova necessidade pode ser uma abordagem mais eficiente.

No exemplo da aula, a refatoração do método de teste foi feita para demonstrar um caso comum em desenvolvimento de software, onde a lógica de negócios muda e os testes existentes precisam ser atualizados para refletir essas mudanças. No entanto, na prática, a decisão de criar um novo método ou refatorar o existente dependeria de uma série de fatores, incluindo o impacto da mudança na base de código existente, a necessidade de manter a funcionalidade antiga, entre outros.

Espero ter ajudado e bons estudos!

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software