Se você está lidando com grandes quantidades de código legado que não está sendo testado atualmente, obter a cobertura de teste agora, em vez de esperar por uma grande reescrita hipotética no futuro, é a decisão certa. Começar escrevendo testes unitários não é.
Sem testes automatizados, depois de fazer qualquer alteração no código, é necessário fazer alguns testes manuais para concluir o teste do aplicativo, para garantir que ele esteja funcionando. Comece escrevendo testes de integração de alto nível para substituir isso. Se o seu aplicativo ler arquivos, validá-los, processar os dados de alguma forma e exibir os resultados desejados, os testes capturam tudo isso.
O ideal é que você tenha dados de um plano de teste manual ou seja capaz de obter uma amostra de dados de produção reais para usar. Se não, já que o aplicativo está em produção, na maioria dos casos ele está fazendo o que deveria ser, portanto, basta criar dados que atingirão todos os pontos altos e assumirão que a saída está correta por enquanto. Não é pior do que tomar uma pequena função, assumindo que está fazendo o que o nome ou qualquer comentário sugere que deveria estar fazendo, 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);
}
Uma vez que você tenha o suficiente desses testes de alto nível escritos para capturar a operação normal dos aplicativos e os casos de erros mais comuns, você precisará gastar tempo no teclado para tentar capturar erros do código fazendo algo além do que você achava que deveria fazer, diminuiria significativamente a refatoração futura (ou mesmo uma grande reescrita) muito mais fácil.
Como você pode expandir a cobertura de teste de unidade, pode reduzir ou até mesmo aposentar a maioria dos testes de integração. Se os arquivos de leitura / gravação do seu aplicativo ou o acesso a um banco de dados, testando essas partes isoladamente e zombando deles ou fazendo seus testes começarem criando as estruturas de dados lidas do arquivo / banco de dados, é um lugar óbvio para começar. Na verdade, 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ê executar 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á ganhando muito.