Se hai a che fare con grandi quantità di codice legacy che non è attualmente in fase di test, ottenere la copertura del test ora invece di aspettare un'ipotetica grande riscrittura in futuro è la mossa giusta. Iniziare scrivendo unit test non è.
Senza test automatici, dopo aver apportato eventuali modifiche al codice, è necessario eseguire alcuni test end-end manuali dell'applicazione per accertarsi che funzioni. Inizia scrivendo test di integrazione di alto livello per sostituirlo. Se la tua app legge i file, li convalida, elabora i dati in qualche modo e visualizza i risultati che desideri test che catturino tutto ciò.
Idealmente avrai dati da un piano di test manuale o sarai in grado di ottenere un campione di dati di produzione reali da utilizzare. In caso contrario, dal momento che l'app è in produzione, nella maggior parte dei casi sta facendo quello che dovrebbe essere, quindi basta creare dati che colpiranno tutti i punti più alti e supponiamo che l'output sia corretto per ora. Non è peggio che prendere una piccola funzione, supponendo che stia facendo quello che è il suo nome o qualsiasi commento suggerisca che dovrebbe fare, e scrivendo test supponendo che funzioni correttamente.
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);
}
Una volta che hai preso abbastanza di questi test di alto livello scritti per catturare il normale funzionamento delle app e i casi di errore più comuni la quantità di tempo che dovrai spendere sulla tastiera per cercare di rilevare errori dal codice facendo qualcosa a parte ciò che pensavate che avrebbe dovuto fare andrebbe in modo significativo, rendendo molto più facile il futuro refactoring (o anche una grande riscrittura).
Dato che puoi espandere la copertura del test dell'unità, puoi ridurre o addirittura ritirare la maggior parte dei test di integrazione. Se i file di lettura / scrittura della tua app o l'accesso a un DB, testare quelle parti in isolamento e deriderle o avviare i test creando le strutture di dati lette dal file / database sono un punto di partenza ovvio. La creazione effettiva di quell'infrastruttura di test richiederà molto più tempo rispetto alla scrittura di una serie di test rapidi e sporchi; e ogni volta che esegui un test di integrazione di 2 minuti invece di spendere 30 minuti manualmente testando una frazione di ciò che i test di integrazione hanno coperto, stai già ottenendo un grosso successo.