Это уже инфраструктурные тесты, не unit-тесты. По большому счету зачитывание реального файла эквивалентно чтению из базы данных или работе с удаленным сервером. Это медленно, использует реальное окружение, и так далее. И если коротко, такие вещи в принципе не приветствуются в юнит-тестах.

Вместо этого обычно вводят какой-нибудь `IDataProvider`, который в юнит-тестах достает таблицы из себя, а в инфраструктурных читает файлы или лезет в БД.

Короче говоря, такие вещи в юнит-тестах держать нельзя, нам уже нужно 2 реализации (txt, mock/stub/dummy), поэтому если хочется иметь подгружаемую таблицу, то нужно идти до конца.

На самом деле я считаю, что мы тут переусердствовали, и платим слишком большую цену за гибкость дизайна. Да, все это полезно, но не факт что нужно, и такая гибкость может никому не понадобиться. 14 файлов для такой тривиальной задачи - это определенно overkill. Разбираться и поддерживать такой код довольно сложно. Нужно проводить разницу между гибкостью которая flexibility и которая agile.