Se você estiver lidando com grandes quantidades de código legado que não está atualmente em teste, obter a cobertura do teste agora, em vez de esperar por uma grande reescrita hipotética no futuro, é a decisão certa. Começar escrevendo testes de unidade não é.
Sem testes automatizados, depois de fazer alterações no código, você precisa fazer alguns testes manuais de ponta a ponta do aplicativo para garantir que ele funcione. Comece escrevendo testes de integração de alto nível para substituir isso. Se seu aplicativo lê arquivos, os valida, processa os dados de alguma maneira e exibe os resultados desejados para os testes que capturam tudo isso.
Idealmente, você terá dados de um plano de teste manual ou poderá obter uma amostra dos dados de produção reais para usar. Caso contrário, como o aplicativo está em produção, na maioria dos casos, ele está fazendo o que deveria ser; então, crie dados que atingirão todos os pontos altos e assumirão que a saída está correta por enquanto. Não é pior do que assumir uma função pequena, supondo que esteja fazendo o que o nome ou qualquer comentário sugere, e escrevendo testes assumindo que está funcionando corretamente.
IntegrationTestCase1()
{
var input = ReadDataFile("path\to\test\data\case1in.ext");
bool validInput = ValidateData(input);
Assert.IsTrue(validInput);
var processedData = ProcessData(input);
Assert.AreEqual(0, processedData.Errors.Count);
bool writeError = WriteFile(processedData, "temp\file.ext");
Assert.IsFalse(writeError);
bool filesAreEqual = CompareFiles("temp\file.ext", "path\to\test\data\case1out.ext");
Assert.IsTrue(filesAreEqual);
}
Depois que você tiver o suficiente desses testes de alto nível escritos para capturar a operação normal dos aplicativos e os casos de erro mais comuns, a quantidade de tempo que você precisará gastar no teclado para tentar detectar erros do código, fazendo algo diferente do que você pensou que deveria fazer isso diminuirá significativamente, facilitando a refatoração futura (ou mesmo uma grande reescrita).
Como você é capaz de expandir a cobertura dos testes de unidade, pode reduzir ou até retirar a maioria dos testes de integração. Se o aplicativo estiver lendo / gravando arquivos ou acessando um banco de dados, testando essas partes isoladamente e zombando delas ou iniciando seus testes criando as estruturas de dados lidas no arquivo / banco de dados, é um ponto óbvio para começar. Criar essa infraestrutura de teste levará muito mais tempo do que escrever um conjunto de testes rápidos e sujos; e toda vez que você executa um conjunto de 2 minutos de testes de integração, em vez de gastar 30 minutos testando manualmente uma fração do que os testes de integração cobriram, você já está obtendo uma grande vitória.