Si está lidiando con grandes cantidades de código heredado que no está actualmente bajo prueba, obtener la cobertura de prueba ahora en lugar de esperar una gran reescritura hipotética en el futuro es la decisión correcta. Comenzar escribiendo pruebas unitarias no lo es.
Sin realizar pruebas automáticas, después de realizar cualquier cambio en el código, debe realizar algunas pruebas manuales de principio a fin de la aplicación para asegurarse de que funciona. Comience escribiendo pruebas de integración de alto nivel para reemplazar eso. Si su aplicación lee los archivos, los valida, procesa los datos de alguna manera y muestra los resultados que desea que las pruebas capturen todo eso.
Lo ideal es que tenga datos de un plan de prueba manual o que pueda obtener una muestra de datos de producción reales para usar. Si no, ya que la aplicación está en producción, en la mayoría de los casos está haciendo lo que debería, así que invente datos que lleguen a todos los puntos altos y suponga que la salida es correcta por el momento. No es peor que tomar una pequeña función, asumiendo que está haciendo lo que se llama o cualquier comentario sugiere que debería estar haciendo, y escribiendo pruebas asumiendo que está funcionando correctamente.
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 vez que haya escrito lo suficiente de estas pruebas de alto nivel para capturar el funcionamiento normal de las aplicaciones y los casos de error más comunes, la cantidad de tiempo que necesitará para golpear el teclado para intentar detectar errores del código haciendo algo. aparte de lo que pensabas que se suponía que iba a hacer, se reducirá significativamente, lo que hará que la refactorización futura (o incluso una gran reescritura) sea mucho más fácil.
Como puede ampliar la cobertura de pruebas unitarias, puede reducir o incluso retirar la mayoría de las pruebas de integración. Si su aplicación está leyendo o escribiendo archivos o accediendo a una base de datos, probar esas partes de forma aislada y burlarse de ellas o comenzar sus pruebas creando las estructuras de datos leídas desde el archivo / base de datos es un lugar obvio para comenzar. En realidad, crear esa infraestructura de prueba llevará mucho más tiempo que escribir un conjunto de pruebas rápidas y sucias; y cada vez que ejecute un conjunto de pruebas de integración de 2 minutos en lugar de pasar 30 minutos probando manualmente una fracción de lo que cubrieron las pruebas de integración, ya está obteniendo una gran ganancia.