Скачать: CL | DM;

Как испольовать Dunit для privat секции?   Найти похожие ветки 

← →
MegaVolt ©   (2006-02-20 13:07) [0]

Идеология Dunit предлогает тестировать только то что видно в интерфейсе пользователю. Внутренняя реализация вроде как может менятся но главное чтобы внешне ничего не поменялось. Что то типа чёрного ящика. Но ведь иногда проще теститровать именно по частям причём эти части пользователям видеть и исспользовать нету необходимости. Что делать?

Т.е. как протестировать privat переменные и функции но при этом оставив их невидимыми для пользователя?

Один вариант это писать тестовый код в том же модуле что и исходный модуль тогда насколько я помню дельфи позволяет вызывать privat методы.

Если ли ещё способы?

---

← →
Mikhail V   (2006-02-20 14:04) [1]

Есть. Использовать директивы прекомпилятора.

---

← →
MegaVolt ©   (2006-02-20 14:12) [2]

Подскажи какие если не сложно?
С примером если не сложно.

---

← →
jack128 ©   (2006-02-20 15:30) [3]

Видимо имеется в виду, что нить типа:

TTestClass = class
{$ifdef TestingInDUnit}
public
{$else}
private
{$endif}
 procedure ProgForTesting;
end;

---

← →
MegaVolt ©   (2006-02-20 16:05) [4]

А в тестирующей проге определять
{$def TestingInDUnit}
так?

---

← →
Ega23 ©   (2006-02-20 16:32) [5]

Я обычно завожу глобальную переменную Debug
Ну и по коду if Debug then ....  какой-нибудь ShowMessage

Ну и запуск с ключом

---

← →
MegaVolt ©   (2006-02-20 16:42) [6]

И как ты по if изменяешь облась видимости переменной или метода?

---

← →
jack128 ©   (2006-02-20 16:48) [7]

Ega23 ©   (20.02.06 16:32) [5]
а почему переменную, а не дерективу ??  Чтобы мусорить release код?
MegaVolt ©   (20.02.06 16:05) [4]
А в тестирующей проге определять
{$def TestingInDUnit}
так
угу.

---

← →
Ega23 ©   (2006-02-20 16:50) [8]

> а почему переменную, а не дерективу ??  Чтобы мусорить release
> код?


Так. Я похоже чего-то не понял.
Что имеется: готовая программа, которую надо тестировать? Или набор исходников, которые надо тестировать?
Если первое, то мне не совсем понятно, как эту директиву "впуздыривать" в программу.
Если второе - то тут я полностью согласен с условной компиляцией.

---

← →
jack128 ©   (2006-02-20 16:57) [9]

Ega23 ©   (20.02.06 16:50) [8]
Или набор исходников, которые надо тестировать?
именно. DUnit тестирует исходники, а не бинарники.

---

← →
Ega23 ©   (2006-02-20 16:58) [10]

> именно. DUnit тестирует исходники, а не бинарники.


А-а-а... Ну тогда с директивами лучше всего, к гадалке не ходи.

---

← →
MegaVolt ©   (2006-02-20 17:16) [11]

Спасибо за помощь :)
Пойду багов щемить :)

---

← →
MegaVolt ©   (2006-02-24 12:52) [12]

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

---

← →
jack128 ©   (2006-02-24 15:06) [13]

Project/Options/  Directories/Conditionals .
Или выносить все дерективы в отбельный файл и подключать его к каждому модулю через {$I defines.inc}

---

← →
MegaVolt ©   (2006-02-24 15:22) [14]

Спасибо. То что нужно.

---

← →
MegaVolt ©   (2006-02-24 15:22) [15]

Спасибо. То что нужно.

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.48 MB
Время: 0.032 c