Solo un FYI: la prueba de la unidad no es equivalente a TDD. TDD es un proceso del cual la prueba unitaria es un elemento.
Dicho esto, si estuvieras buscando implementar pruebas unitarias, hay varias cosas que podrías hacer:
Se han probado todos los nuevos códigos / mejoras
De esta manera, no tienes que pasar por una prueba unitaria y todo lo que ya existe, por lo que la fase inicial de la implementación de la prueba unitaria es mucho más pequeña.
Probar datos individuales
La prueba de algo que puede contener grandes cantidades de datos puede llevar a muchos casos extremos y brechas en la cobertura de la prueba. En su lugar, considere la opción 0, 1, muchos. Pruebe un 'lote' con 0 elementos, 1 elemento y muchos elementos. En el caso de 1 elemento, pruebe las diversas permutaciones en las que se pueden encontrar los datos para ese elemento.
Desde allí, pruebe los casos de borde (límites superiores al tamaño de los elementos individuales y la cantidad de elementos en el lote). Si ejecuta las pruebas con regularidad y tiene pruebas de larga ejecución (¿lotes grandes?), La mayoría de los corredores de pruebas permiten la categorización para que pueda ejecutar esos casos de prueba por separado (¿todas las noches?).
Eso debería darte una base sólida.
Utilizando datos reales
La alimentación de datos 'reales' utilizados anteriormente como lo está haciendo ahora no es una mala idea. Simplemente complételo con datos de prueba bien formados para que sepa inmediatamente puntos específicos de falla. Si no se manejan los datos reales, puede inspeccionar los resultados del proceso por lotes, realizar una prueba unitaria para replicar el error y luego volverá a rojo / verde / refactor con casos de regresión útiles.