Спасибо за ваши мысли. Благодаря Вашим ответам, да и и других участников тоже, но почему-то Ваши сыграли окончательный результат больше и он меня устроил.
К чему конкретно я пришел?
Юнит-тесты никаким образом не должны взаимодействовать с файловой системой!
Любой тест с файлом можно сделать ограниченным. Выдрать необходимые строго для этого юнит-теста данные из файла, оформить эти данные в виде исходного кода. К примеру положить эти данные в массива байт и создать Мок-класс по работе с этим массивом. Перед добавлением новых тест.данных логично просмотреть имеющиеся тесты на предмет подходящих уже имеющихся тест.данных. Если таковых нет, то попытаться изменить их так, чтобы не пришлось добавлять новых. Все это приведет к тому что малым набором тест.данных можно будет протестировать Всю написанную на данный момент функциональность.
Тогда возникает вопрос: А что если надо работать с файлами? Этот ответ можно получить с помощью другого типа тестирования «интеграционный тест». Работа с файлами для этого тип тестирования лучше всего ложится.
Еще одна мысль, к которой пришел при решении этого вопроса:
Когда мы используем юнит-тестирование, то на самом деле в процессе разработки возникает 2 набора API. Это не просто 2 типа кода: приложение и юнит-тесты. Это немного другое. Юнит-тесты это прежде всего код! И с этим кодом мы поступаем также как и привыкли, что-то обобщая выносим в доп. функции, что-то выпиливаем, что-то добавляем. В процессе этого мы неизбежно создаем еще один API для тестирования.
Итог рассуждений: Получается что когда мы пишем основной код мы создаем один тип API, специфичный для этого проекта(набор компонентов, их взаимодействие, дока к ним если они получаются неявными, код приложения их связывающая). Но также при написании юнит-тестов мы неизбежно и другой API для тестирования.
Так. Вернемся к условиям моего вопроса. Мой вопрос связан с юнит-тестами. Их ключевая роль частота запуска, а чтобы их хотелось чаще запускать они должны быстро работать и «быть под рукой». Мои юнит-тесты достаточно быстры, но они «не под рукой». Потому что переключить себя на компиляцию и запуск приложения с юнит-тестами это «далековато» как-то! Они должны быть «ближе» ;) Мне как раз и хочется организовать работу с юнит-тесами так, чтобы они были «очень близко» и чтобы у меня не возникало желания запустить их после достаточно большого кол-ва правок кода. А если фоновый режим, то это можно будет сделать только применяя CLang, а остальные мне кажутся монстроподобными динозаврами, а переход на CLang не готов, т.к. под виндами не очень-то он хорошо поддерживается )
Т.е. у Вас запуск юнит тестов отдельным приложением так? Если да, то это ничем не отличается от того что я сейчас использую. Но это мне уже не подходит. Когда работа кипит, так и хочется сказать «Вот ща вот это еще допишу, и протестю», а все потому что переключение на тестовое приложение не достаточно быстро, чтобы эту операцию не откладывать. Грубо говоря, переключение на «тестирование» при использовании метода отдельного приложения, это своего рода смена деятельности мозга, а это хочется избежать ибо теряется азарт при решении основной задачи
Пока вижу, что самое дешевое решение это новая конфигурация. От TestExplorer как я понимаю, я получу только разноцветные прошел\упал. Ну и playlist, но этого же можно достигнуть и в случае использовании конфигурации, где я должен в ручную исключать юнит-тесты из проекта
>>Если ваш код требует на вход объект StreamPtr_t (какое странное название)
Вам больше нравится применять «boost::shared_ptr< StreamIfce_t >»? На мой взгляд лучше сделать typedef и применять уже его
Кто это сказал? В случае стаба очень даже можно нагрузить чтением файла. Напомню, что цель стаба предоставить тест.данные, а цель мока проверить поведение.
Хорошо. Придется погружаться в детали ;)
Тест №1: Отваливаемся если неправильная сигнатура №1, которая указана в одном из файловых заголовков
Тест №2: Если пройдет тест1, то проверяем сигнатуру №2, которая указана уже в другом заголовке
…
Тест № ЭН
На каждый тест нужно файл, т.к. расположение заголовков не тривиальное
Что лучше? Массив байтов в исходном коде или мок\стаб читающий тестовый файл?
вот сейчас у меня в качестве тест.данных используются 5 файлов. Я думаю как их лучше использовать? Также читать с диска как и прежде я это делал(вариант №1) или все-таки лучше в массив байт(вариант №2)?
Судя по комментариям ребята не понял сути вопроса.
Вопрос не с реализацией логики самого тестируемого класса. Вопрос связан с организацией хранения и подаче тестовых данных. Как я уже перечислил можно хранить в вариантах выше. Можно хранить в виде файла, а можно и в виде массива байт в исходном коде. Можно написать мок или стаб, которые будут читать файл или массив байтов из исходного кода.
Думаю сейчас стало понятнее что моя проблема не в организации самого объекта тестирования, а вопрос в процессе тестирования. Мне нужно определить как с хранением тест.данных и механизмами их чтения
Я написал уточнение ;) Но думаю по скайпу ты уже видел примеры исходного кода ) Вопрос связан с хранением и подаче тестовых данных. Мы же их должны как-то подавать, как? Мок или стаб? Также нужно тест.данные хранить, как это сделать? В виде файла или в виде массива байт в исходном коде?
Написал уточнение. Видимо мой вопрос не совсем был ясен.
>>Нужно отделить логику чтения файла от логики его обработки
Вы говорите о реализации. Я не спрашивал о том как же мне реализовать логику. Мой вопрос связан с организацией хранения и подаче тестовых данных.
У меня пока класс по работе с форматом сделан так:
class PeImage
{
public:
explicit PeImage( StreamPtr_t stream );
У меня работа с форматом уже не зависит от представления данных: файл, сеть или еще что-то. Но когда мы начинаем тестировать, мы все равно что-то должны подать и уже не абстрактное, а конкретное!
1) Есть расширение mercurial.selenic.com/wiki/PurgeExtension, пока его попробую. Не любитель ставить расширения, т.к. то что есть у меня не факт что есть у другого.
2) Для UNIX-подобных есть метод«hg st -nu | xargs rm»
Можно поискать готовые переводы для уже существующих вещей, к примеру вот:
1) CVS. В ней checkout точно есть и наверняка за столько времени ее сущестования кто-то да перевел!
2) Обычные команды входящие в базовый UNIX-toolchain: mv,rm, etc
К чему конкретно я пришел?
Юнит-тесты никаким образом не должны взаимодействовать с файловой системой!
Любой тест с файлом можно сделать ограниченным. Выдрать необходимые строго для этого юнит-теста данные из файла, оформить эти данные в виде исходного кода. К примеру положить эти данные в массива байт и создать Мок-класс по работе с этим массивом. Перед добавлением новых тест.данных логично просмотреть имеющиеся тесты на предмет подходящих уже имеющихся тест.данных. Если таковых нет, то попытаться изменить их так, чтобы не пришлось добавлять новых. Все это приведет к тому что малым набором тест.данных можно будет протестировать Всю написанную на данный момент функциональность.
Тогда возникает вопрос: А что если надо работать с файлами? Этот ответ можно получить с помощью другого типа тестирования «интеграционный тест». Работа с файлами для этого тип тестирования лучше всего ложится.
Еще одна мысль, к которой пришел при решении этого вопроса:
Когда мы используем юнит-тестирование, то на самом деле в процессе разработки возникает 2 набора API. Это не просто 2 типа кода: приложение и юнит-тесты. Это немного другое. Юнит-тесты это прежде всего код! И с этим кодом мы поступаем также как и привыкли, что-то обобщая выносим в доп. функции, что-то выпиливаем, что-то добавляем. В процессе этого мы неизбежно создаем еще один API для тестирования.
Итог рассуждений: Получается что когда мы пишем основной код мы создаем один тип API, специфичный для этого проекта(набор компонентов, их взаимодействие, дока к ним если они получаются неявными, код приложения их связывающая). Но также при написании юнит-тестов мы неизбежно и другой API для тестирования.