Как тестировать в DUnit классы которые куда то отдают результат?

← →
MegaVolt © (2005-09-23 13:19) [0]

Есть некий класс например закрашивающий некую область экрана. Как оттестировать правильность работы алгоритма. Считаем что доступа к пикселям у нас нету (я хочу на основе этого примера понять как правильно писать тесты для классов отдающих выходные данные за пределы досягаемости например во внешнее устройство, на принтер или ещё куда). Т.е. на входе в тесте я создаю некую границу и отдаю комманду закрасить. Что я должен анализировать на выходе? Некий массив пикселов который сгенерит модуль? Значит должен быть какой то механизм последующего отображения этих данных на экран?

Или я вместо экрана подсовываю заменитель из которого могу вычитывать выходные данные?

И второй вопрос:
В экстремальном программировании пишут что тесты не должны зависить друг от друга но если у меня есть иерархия из классов то проверяя последний класс я обязательно вызову методы предков. Получается что я не могу отдельно проверить потомка. Или есть какие то хитрости?

Огромное спасибо всем кто сможет что то порекомендовать или направить на соответствующий ресурсик.

← →
Игорь Шевченко © (2005-09-23 13:24) [1]

> Есть некий класс например закрашивающий некую область экрана

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

> В экстремальном программировании пишут что тесты не должны
> зависить друг от друга но если у меня есть иерархия из классов
> то проверяя последний класс я обязательно вызову методы
> предков. Получается что я не могу отдельно проверить потомка.
> Или есть какие то хитрости?

Вызовешь методы уже оттестированных предков. Какие сложности ?

← →
MegaVolt © (2005-09-23 13:52) [2]

>С таким же успехом он может закрашивать и Bitmap

Но ведь для работы программы Bitmap не нужен? Получается что я для того чтобы оттестировать прогу замедляю её работы :( А как сделать так чтобы этот Bitmap был только при тестировании?

>Другое дело, что я не уверен, что в данном случае надо применять unit-тестирование.

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

>Вызовешь методы уже оттестированных предков. Какие сложности ?

Так если в предке напортачил то не пройдут и остальные тесты т.е. из-за одной ошибки могут вообще все тесты непройти. А на сате про ХР пишут что этого нужно избегать и делать тесты независимыми. Или я неправильно понимаю это утверждение.

← →
Игорь Шевченко © (2005-09-23 13:59) [3]

MegaVolt © (23.09.05 13:52) [2]

> А на сате про ХР пишут что этого нужно избегать и делать
> тесты независимыми. Или я неправильно понимаю это утверждение

А кто-то мешает в группе тестов сначала тесты предков пропускать ?

> А как сделать так чтобы этот Bitmap был только при тестировании?

Обычно. Выводить в Device Context, например.

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

Куда и зачем уходят ?

← →
MegaVolt © (2005-09-23 14:22) [4]

> Обычно. Выводить в Device Context, например.

Извиняюсь но я не знаю что это такое :( Можно небольшой ликбез на эту тему?

> Куда и зачем уходят ?

Ну например комманды управления неким устройством. Т.е. по нажатию кнопки я должен послать в устройство (например порт) некую последовательность байт. Как проверить то ли я посылаю?

← →
jack128 © (2005-09-23 15:01) [5]

MegaVolt © (23.09.05 14:22) [4]
Извиняюсь но я не знаю что это такое :(

DC. Объектная оболочка над контекстом устройства в дельфи называется TCanvas. Не уж то не знаешь, что это такое ? ;) Как же ты тогда рисуешь что то??

← →
MegaVolt © (2005-09-23 15:17) [6]

Tcanvas само собой знаю а вот название Device Context непробегало :)

>Выводить в Device Context, например.

Т.е. класс должен уметь выводить результаты туда куда я ему скажу? Ясненько.

А как быть с поротом и последовательностью байтиков? Тоже подсовывать виртуальный порт и смотреть что туда записалось?

← →
Игорь Шевченко © (2005-09-23 15:52) [7]

> А как быть с поротом и последовательностью байтиков? Тоже
> подсовывать виртуальный порт и смотреть что туда записалось?
>

Разумеется. Только зачем именно порты таким образом мучить ? Достаточно просто нужную последовательность байт выводить куда угодно. А для порта пользоваться уже отлаженным транспортом.

← →
MegaVolt © (2005-09-23 15:59) [8]

> Только зачем именно порты таким образом мучить ? Достаточно просто нужную последовательность байт выводить куда угодно. А для порта пользоваться уже отлаженным транспортом.

А как совместить вывод куда угодно с тем что код для тестирования и в боевой программе должен быть одним и тем же? Т.е. я где то должен указывтаь что вывод не в порт а в поток например?

> А как совместить вывод куда угодно с тем что код для тестирования
> и в боевой программе должен быть одним и тем же?

Иерархию классов грамотно спроектировать, для начала. Класс для абстрактного вывода, класс для конкретного вывода и т.д.

>Иерархию классов грамотно спроектировать, для начала. Класс для абстрактного вывода, класс для конкретного вывода и т.д.

А можно мини примерчик? Где есть вывод на несколько устройст и переключатель для выбора их? Пли-и-и-из :)

Если в порт идёт запись WriteFile, то почему бы не использовать THandleStream, которому в конструкторе передан хендл порта, а переменную объявить как TStream. Для записи куда-либо ещё - другой наследник TStream.

Как тестировать в DUnit классы которые куда то отдают результат? Найти похожие ветки