Test musi być niezależny i na każdym środowisku się dopalić, więc warto tutaj generować te dane w kodzie, ew. użyć tego csv, ale z poziomi resource i osadzić w aplikacji. Zależność, od pliku zewnętrznego to kiepska praktyka da testów. Zresztą testy to ja bym napisał najpierw, a potem pisał implementacje, aż testy zrobią się zielone. Pisząc testy post factum, tak w zasadzie masz już umysł skazany daną implementacją i trudno będzie wszystko wymyślić. Jak dobrze zaprojektujesz testy i zrobisz implementacje na zielono, to zysk jest też taki, że pilnują Ci integralności kodu - czyli jak za rok zrobisz modyfikacje i jakiś test wyjdzie na czerwono to masz lampke alarmową - uwaga coś się dzieje - i albo faktycznie błąd algorytmu, lub zmiana założeń, dopuszcza złamanie testu - co trzeba uwzględnić, wszak testy też podlegają utrzymaniu. Testy sygnalizują, a nie diagnozują. Osobiście pisał bym nadmiarowe metody testujące, żeby ich nazwy już dokumentowały co testują. Mając jedną metodę ogólną i 150 wartości w csv czy tablicy nic ci nie mówi, jak wysypie się test ExecuteAllTests(), na przetwarzaniu lini 53 csv z testami. Co innego jak wysypie się metoda CheckNonNumericValueInAgeProperty();