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

Question

[Дмитрий]

Цель вопроса выразить просьбу поделиться опытом кто и как пишет юнит-тесты для классов нацеленных на работу с файлом подчиняющегося какому-либо формату?


Итак.

Сейчас пишу библиотеку по работе с определенным форматом файла, все мои юнит-тесты при проверке тем или иным образом используют файлы. Файловый путь к тестовым файлам формирую в исходнике путем питон-скрипта, который отрабатывает перед компиляцией.


Nota Bene: Я сознательно не указываю среду разработки и язык программирование. Уверен что техники юнит-тестирования не зависят от языка или IDE.


Уже который раз задаюсь вопросом: А как лучше всего организовать юнит-тест работающий с тестовым файлом?


Варианты приходящие в голову:

1) Просто ложить в некую папку набор тестовых файлов и указывать пукть к этой папке юнит-тестам. Этим способом сейчас и пользуюсь

2) Можно тест-файлы перевести в символьную форму, вида "\x4a\x4B\xa9" и тогда не надо будет указывать файловый путь, но по сути это теже самые тестовые файлы, только немного по-другому представлены


+ ко всему меня еще смущает работа с файлами тем что это похоже на «интеграционный» тип тестирования, а этим не должен заниматься юнит-тест.


P.S.:

Пока склоняюсь к мысли, что вариант два все-таки имеет смысл, но это означает мне надо будет написать достаточно большое количество тестового кода, своего рода Test API для тестирования моей библиотеки. Поэтому стоит вопрос будет ли это оправданным, ответ на который голова пока обдумывает?!

Comments

[Дмитрий]

У меня пока класс по работе с форматом сделан так:

class PeImage
{
public:
   explicit PeImage( StreamPtr_t stream );

У меня работа с форматом уже не зависит от представления данных: файл, сеть или еще что-то. Но когда мы начинаем тестировать, мы все равно что-то должны подать и уже не абстрактное, а конкретное!

[Дмитрий]

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

Думаю сейчас стало понятнее что моя проблема не в организации самого объекта тестирования, а вопрос в процессе тестирования. Мне нужно определить как с хранением тест.данных и механизмами их чтения

Answer 1

[serso]

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

Comments

[arturich]

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

[Дмитрий]

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

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

[serso]

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

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)?

[serso]

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

[Дмитрий]

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

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

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

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

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

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

Answer 2

[ixSci]

читай про mock'и и используй их. Физическое чтение с ФС производить излишне, ты же не драйвер ФС пишешь, а значит тестировать надо твою логику.

Comments

[Дмитрий]

Я написал уточнение ;) Но думаю по скайпу ты уже видел примеры исходного кода ) Вопрос связан с хранением и подаче тестовых данных. Мы же их должны как-то подавать, как? Мок или стаб? Также нужно тест.данные хранить, как это сделать? В виде файла или в виде массива байт в исходном коде?

[ixSci]

Если данных не много, тогда прямо в коде. Если много, то лучше вынести в файл. С другой стороны я не очень понимаю, как может быть много данных в тесте. Ты должен подготовить искусственные данные для теста каждого метода, а они не будут большими, я полагаю.

[Дмитрий]

Ну к примеру возьмем задачу «Проверить корректность вычисления файлового офсета оверлея для файла». Эта задачу уже требует файла размером минимум 1КБ!

[ixSci]

Ты прекрати по китайски изъясняться :) 1Kb данных это массив из 1024*8 char'ов. Его можно забить чем угодно, хоть нулями. И обрамить полезными данными, которые дают ветвление в твоём коде. В целом ничего сложного, просто над тестами нужно подумать и скармливать тесту только те данные, которые, непосредственно, этот метод анализирует.

[Дмитрий]

Хорошо. Придется погружаться в детали ;)
Тест №1: Отваливаемся если неправильная сигнатура №1, которая указана в одном из файловых заголовков
Тест №2: Если пройдет тест1, то проверяем сигнатуру №2, которая указана уже в другом заголовке
…
Тест № ЭН

На каждый тест нужно файл, т.к. расположение заголовков не тривиальное

Что лучше? Массив байтов в исходном коде или мок\стаб читающий тестовый файл?

[ixSci]

с таким подходом — всё равно. Выбирай, что больше нравится. Тут нет никаких объективных причин отдавать предпочтение любому из этих вариантов.

[ixSci]

P.S. и mock и stub предназначены для того, чтобы файл не читать.

[Дмитрий]

Кто это сказал? В случае стаба очень даже можно нагрузить чтением файла. Напомню, что цель стаба предоставить тест.данные, а цель мока проверить поведение.

Answer 3

[arturich]

Модульные тесты модульными называются потом, что тестируют модуль изолировано. Зависимойстей, по хорошему, быть не должно, иначе это уже будет что-то вроде интеграционного тестирования.

Однако, как часто бывает, проблема в другом) Всегда надо быть уверенным, что модульный тест сейчас для вас лучший вариант, так как довольно часто получается, что самым выгодным получается написание функционального теста и «дело в шляпе» как говорится. Это позволяет рефакторить большой модуль и не бояться постоянного падения тестов из-за того, что какой-то класс поменял api. Функциональные тесты часто тратят гораздо меньше времени, но, конечно, это не серебряная пуля и модульные тоже нужны.

Скажем так, что в вакууме модульные тесты нужны программистам для рефакторинга, а функциональные нужны заказчику.

Answer 4

[egorinsk]

> + ко всему меня еще смущает работа с файлами тем что это похоже на «интеграционный» тип тестирования, а этим не должен заниматься юнит-тест.

Юнит-тесту никто не запрещает прочитать файл в память до тестирования и отдавать тестируемому коду уже набор байт из памяти или что он там принимает на вход. Если ваш код требует на вход объект StreamPtr_t (какое странное название), то сделайте специально для тестов простейший MemoryStreamReader на 20 строчек.

Если боитесь, что файл может прочитаться неправильно (хотя вряд ли такое возможно) и сломать вам тест, сделайте подсчет какой-нибудь контрольной суммы.

А специально превращать файлы в портянки вроде "\xff" смахивает на извращение.

Comments

[Дмитрий]

>>Если ваш код требует на вход объект StreamPtr_t (какое странное название)
Вам больше нравится применять «boost::shared_ptr< StreamIfce_t >»? На мой взгляд лучше сделать typedef и применять уже его