Solo una FYI: il test dell'unità non è equivalente a TDD. TDD è un processo in cui il test unitario è un elemento.
Detto ciò, se stavi cercando di implementare i test unitari, ci sono un sacco di cose che potresti fare:
Tutti i nuovi codici / miglioramenti sono testati
In questo modo non devi passare e testare tutto ciò che esiste già, quindi la gobba iniziale del test dell'unità di implementazione è molto più piccola.
Verifica singoli pezzi di dati
Il test di qualcosa che può contenere grandi quantità di dati può portare a molti casi limite e lacune nella copertura del test. Invece, considera l'opzione 0, 1, molte. Prova un 'gruppo' con 0 elementi, 1 elemento e molti elementi. Nel caso di 1 elemento, verifica le varie permutazioni in cui possono essere contenuti i dati per quell'elemento.
Da lì, prova i casi limite (limiti superiori alla dimensione dei singoli elementi e quantità di elementi nel batch). Se si eseguono regolarmente i test e si eseguono test a lungo termine (lotti di grandi dimensioni?), La maggior parte dei test runner consente la categorizzazione in modo che sia possibile eseguire tali test case separatamente (di notte?).
Questo dovrebbe darti una base strong.
Utilizzo dei dati reali
L'inserimento di dati "effettivi" precedentemente utilizzati come quello che stai facendo ora non è una cattiva idea. Basta integrarlo con dati di test ben formati in modo da conoscere immediatamente specifici punti di errore. In caso di mancata gestione dei dati effettivi, è possibile esaminare i risultati del processo batch, produrre un test unitario per replicare l'errore, e quindi tornare in rosso / verde / refactoring con casi di regressione utili.