Как правильно писать юнит-тест для класса работающего с файлом?

Соглашусь с вами, поток на вход, действительно лучший вариант на мой взгляд.

Написал уточнение. Видимо мой вопрос не совсем был ясен.

>>Нужно отделить логику чтения файла от логики его обработки
Вы говорите о реализации. Я не спрашивал о том как же мне реализовать логику. Мой вопрос связан с организацией хранения и подаче тестовых данных.

Если у вас уже отделена логика чтения от логики процессинга, то вам всего лишь остаётся передать в качестве параметра простой поток (например, поток который читает из строки зашитой в файл юнит теста).
Пример на псевдокоде:

class ProcessingTest {

constant TEST_DATA _01 = "12312dffgerg34tegdg";
constant TEST_DATA _02 = "12sdf31sdgf2dffgerg34tegdg";

method testProcessing() {
     // create and init object to be tested

     // do test
     result = object.read(new TestStringStream(TEST_DATA_01));

     // check if result is correct
}


    inner class TestStringStream extends Stream {
        // simple implementation
    }
}

Также вы можете посмотреть в сторону библиотек или уже готовых юнит-фреймворков на вашем языке, возможно там уже есть нужные вспомогательные классы (например, TestStringStream из примера выше)

constant TEST_DATA _01 = "12312dffgerg34tegdg";
constant TEST_DATA _02 = "12sdf31sdgf2dffgerg34tegdg";

вот сейчас у меня в качестве тест.данных используются 5 файлов. Я думаю как их лучше использовать? Также читать с диска как и прежде я это делал(вариант №1) или все-таки лучше в массив байт(вариант №2)?

На самом деле не особо важно каким образом вы данные получаете — делайте как быстрее или как удобнее вам. Всё-таки цель теста проверить функционал, а не тратить время на его написание. Конечно, тест придётся ещё и поддерживать, и расширять, если понадобится — это не стоит забывать. Я в своей практике использую оба подхода — иногда зашиваю исходные данные в сам юнит тест, иногда кладу его рядом и читаю отдельно. Думаю, второй вариант предпочтительнее, когда файлы большие и, например, форматируемые (json, xml).

Спасибо за ваши мысли. Благодаря Вашим ответам, да и и других участников тоже, но почему-то Ваши сыграли окончательный результат больше и он меня устроил.

К чему конкретно я пришел?

Юнит-тесты никаким образом не должны взаимодействовать с файловой системой!
Любой тест с файлом можно сделать ограниченным. Выдрать необходимые строго для этого юнит-теста данные из файла, оформить эти данные в виде исходного кода. К примеру положить эти данные в массива байт и создать Мок-класс по работе с этим массивом. Перед добавлением новых тест.данных логично просмотреть имеющиеся тесты на предмет подходящих уже имеющихся тест.данных. Если таковых нет, то попытаться изменить их так, чтобы не пришлось добавлять новых. Все это приведет к тому что малым набором тест.данных можно будет протестировать Всю написанную на данный момент функциональность.

Тогда возникает вопрос: А что если надо работать с файлами? Этот ответ можно получить с помощью другого типа тестирования «интеграционный тест». Работа с файлами для этого тип тестирования лучше всего ложится.

Еще одна мысль, к которой пришел при решении этого вопроса:
Когда мы используем юнит-тестирование, то на самом деле в процессе разработки возникает 2 набора API. Это не просто 2 типа кода: приложение и юнит-тесты. Это немного другое. Юнит-тесты это прежде всего код! И с этим кодом мы поступаем также как и привыкли, что-то обобщая выносим в доп. функции, что-то выпиливаем, что-то добавляем. В процессе этого мы неизбежно создаем еще один API для тестирования.

Итог рассуждений: Получается что когда мы пишем основной код мы создаем один тип API, специфичный для этого проекта(набор компонентов, их взаимодействие, дока к ним если они получаются неявными, код приложения их связывающая). Но также при написании юнит-тестов мы неизбежно и другой API для тестирования.