Escrevendo testes para código cujo propósito eu não entendo

Você está indo bem!

Criar testes de regressão automatizados geralmente é a melhor coisa que você pode fazer para tornar um componente refatorável. Pode ser surpreendente, mas esses testes podem ser escritos sem o entendimento completo do que o componente faz internamente, contanto que você entenda as "interfaces" de entrada e saída (no significado geral da palavra). Fizemos isso várias vezes no passado para aplicativos legados completos, não apenas para as classes, e isso nos ajudou a evitar quebras que não entendíamos completamente.

No entanto, você deve ter dados de teste suficientes e ter certeza de que a empresa entende o que o software faz do ponto de vista de um usuário desse componente, caso contrário você corre o risco de omitir casos de teste importantes.

É IMHO uma boa ideia implementar seus testes automatizados antes de começar a refatorar, não depois, para fazer a refatoração em pequenas etapas e verificar cada etapa. A refatoração em si deve tornar o código mais legível, por isso, ajuda-o a aumentar o seu conhecimento das partes internas pouco a pouco. Portanto, as etapas da ordem nesse processo são

1. compreenda o código "de fora",
2. escreve testes de regressão,
3. refatorar, o que leva a um melhor entendimento dos componentes internos do código

Uma razão importante para escrever testes unitários é que eles documentam a API do componente de alguma forma. Não entender o propósito do código em teste é realmente um problema aqui. A cobertura do código é outro objetivo importante, difícil de alcançar sem saber quais ramificações de execução existem e como elas são acionadas.

No entanto, se for possível redefinir o estado de forma limpa (ou construir o novo objeto de teste toda vez), pode-se escrever testes de tipo "trash out-out" que apenas alimentam entradas aleatórias no sistema e observam a saída .

Tais testes são difíceis de manter, como quando eles falham, pode ser complexo dizer por que e quão sério é. A cobertura pode ser questionável. No entanto, eles ainda são muito melhores que nada. Quando tal teste falha, o desenvolvedor pode revisar as alterações mais recentes com mais atenção e, esperamos, identificar o erro lá.