Você herda um serviço sem testes e precisa mudar a lógica central dele. Como você aborda isso?

Fixe o comportamento atual antes de mudar. Escreva testes de caracterização numa fronteira estável, alimentando entradas reais e afirmando o que o código faz hoje, bugs incluídos, para você ter uma rede que detecta mudança. Depois refatore em passos pequenos com esses testes verdes, extraindo a lógica que você precisa tocar para algo testável. Só quando a costura existir é que você muda comportamento, e cada mudança ganha o próprio teste.

Eu não mudo lógica que não consigo verificar, então o passo um é uma rede. Eu escrevo testes de caracterização na fronteira estável mais alta, geralmente o handler HTTP ou um ponto de entrada do serviço, e afirmo o que o código faz agora, incluindo coisas que eu suspeito serem bugs. O objetivo não é correção, é detectar mudança. Se eu tenho acesso a produção eu capturo algumas centenas de pares reais de request e resposta, porque entradas feitas à mão perdem as esquisitas e são justamente as esquisitas que quebram. Depois eu refatoro em passos pequenos com os testes verdes o caminho inteiro, puxando a lógica que eu de fato preciso tocar para uma função que eu consigo chamar direto. Só então eu mudo comportamento, e cada mudança vem com um teste de verdade mais uma decisão sobre se o comportamento antigo era intencional. Num serviço legado de precificação eu fiz exatamente isso e o tráfego capturado expôs dois caminhos de arredondamento que discordavam, o que ninguém sabia. É o tipo de coisa que você acha com uma rede e destrói sem uma.