Unit tests. Советы требуются

← →
pasha_golub © (2009-08-24 13:25) [0]

Решил, что стоит подвергнуть себя данной штуке. Поковырялся малек. Вроде все шикарно и понятно.

Вопросы следуюшего толку.

1. Есть ли возможность логировать все это дело в файл? (имеется ввиду без ручной работы, в стандарте есть ли?)
2. Есть ли возможность подготавливать весь тест, а не каждый чек методами SetUp и TearDown?

В двух словах я хочу сделать такую штуку. Батник, который проходится по ревизиям SVN, переключается на каждую из ревизий, билдит тестовый проект, запускает его. Идет лог. И так для каждой ревизии. Потом я хочу построить гистограмму, например, и посмотреть не только факт прохождения теста, но и скорость (увеличилась ли\уменьшилась).

Если у кого есть идеи, не связанные с DUnit"ом, буду рад услышать. Ибо в настоящий момент пользуемся наколеннописанной приблудой и меня это немножко бесит.

← →
Игорь Шевченко © (2009-08-24 13:35) [1]

1. Стандартов никаких нет
2. Ты можешь делать все, как считаешь нужным, но у DUnit система следующая: setup теста, тест, teardown теста. Что внутри теста находится - на совести разработчика.

У меня в одном из тестов в setup поднимается база из дампа :)

← →
pasha_golub © (2009-08-24 14:04) [2]

> Игорь Шевченко © (24.08.09 13:35) [1]

> У меня в одном из тестов в setup поднимается база из дампа
> :)

Вот об этом-то и речь. Что у меня, в принципе, очень большое кол-во тестов будет работать с базой. А получается, что SetUp будет исоплнятся для каждого Check_xxxx. А я хочу исполнить сетап для всего Suite.

Код есть, конечно, можно руками все дописать. Но мало ли... может есть какие-то общепринятые нормы. Опять же Test Decorator"s присутствуют, а по ним мануалы скудны.

← →
atruhin © (2009-08-24 19:29) [3]

Не понятно в чем проблемма. Действия которые нужно сделать однократно, и не нужно тестировать,
например открыть БД, размещай в dpr. Если это открытие нужно тестировать, размещай в первом тесте,
благо они по очереди выполняются. SetUp можешь не использовать, если не нужно.
Вообще если разобраться DUnit очень удобная оболочка для тестов.

← →
pasha_golub © (2009-08-25 16:19) [4]

> atruhin © (24.08.09 19:29) [3]

> Вообще если разобраться DUnit очень удобная оболочка для
> тестов.

Это если разобраться. :)) А я ж с перепугу полезу генофонд ей кроить по своему разумению :)

← →
Kolan © (2009-08-25 16:29) [5]

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

А вот как доходит до практики. Более или менее сложные методы я не понимаю как завернуть в тесты.

Например. Вполне логично тестировать методы контроллера. Скажем в контроллере программы, которая сейчас открыта у меня в ИДЕ есть метод SendTerminalString. Он асинхронно тосылает данные в железку.

{{{
procedure TSystemController.SendTerminalString(const S: string);
begin
FDeviceProtocol.TerminalSendString(S);
end;
}}}

А та ему может быть отвечает. И как такое загонять в тест?

← →
Игорь Шевченко © (2009-08-25 16:59) [6]

Kolan © (25.08.09 16:29) [5]

> Игорь, а где можно прочесть про практическое применения
> тестов

Кент Бек целую книжку выпустил: http://www.rsdn.ru/res/book/prog/beck.xml

> А та ему может быть отвечает. И как такое загонять в тест?

Обычно при тестах какая-то из сторон протокола представляется эмулятором

← →
Kolan © (2009-08-25 17:04) [7]

Да, не читал, спасибо.

← →
atruhin © (2009-08-25 17:05) [8]

> [5] Kolan © (25.08.09 16:29)

Попробую я ответить.
DUnit это порт на Delphi JUnit, а по нему в инете куча инфы, в том числе на русском. Твой пример для DUnit не предназначен. Вообще когда то, я много работал с оборудованием, мы
для тестирования писали модуль эмуляции устройства, который возвращает, все возможные варианты данных, допустимых для устройства, включая критические значения. Далее {$ifdef ...} вместо реальной работы с устройством, подключаем модуль эмуляции, и тестирум ПО. Помимо тестирования, данный подход, позволяет вести разработку ПО без наличия устройства под рукой. И вот в данном варианте, уже можно методы обработки данных, тестировать с помощью DUnit.

← →
atruhin © (2009-08-25 17:10) [9]

Пока писал, Игорь опередил :). Но, хотя мы данный подход, с эмуляторами, применяли лет 10 назад, ничего не меняется под луной :).

← →
Суслик_ (2009-08-25 20:19) [10]

1) Лирика.

Тесты, романтика ))

Вообще все это хорошо, но трудоемко имхо изрядно.
Я, безусловно, выступаю за юнит тесты, но сам их делать перестал, ибо трудоемко.

Паша, не знаю, какая у тебя ситуация и сколько работает над проектом человек, но мое имхо, что грошь цена юнит-тестам, если их не будут добросовестно делать ВСЕ участники коллектива. С грошом я может погорячился - для себя польза всегда есть. Но вот чтобы была польза для всего проекта нужен отдел тестирования, который и будет тем цербером, который не пропускает что-то без юнит тестов. Отдел тестирования может заменить ответственный разработчик (желательно покрупнее), который будет стрясывать эти тесты. Может даже разработчик тут лучше - ибо видя историю SVN (CVS, что у тебя, не знаю) может сам определять потребность в новых тестах.

2) Насчет БД.
В любом побочном деле что главное? Правильно - инструкция. Не сказать, что для главного дела инструкция не нужна, но обычно ты находишься в потоке главной разработки и может некоторыми элементами документации по ней пренебречь (и так помнишь, все что нужно). А вот тестирование, все же не основная твоя работа. Поэтому нужно просто все хорошо описать. В частности, описать условия применимости теста - например, для проведения этого теста требуется такая-то БД. Хотя, можно и автоматизировать данный процесс - зависит от ситуации. Те тесты, которые я раньше написал и все же иногда использую, у меня так и сделано - нужна такая-то эталонная БД, которую я каждый раз поднимаю и оставляю тесты на ночь.

← →
pasha_golub © (2009-08-26 18:18) [11]

> Вообще все это хорошо, но трудоемко имхо изрядно.

Трудоемко. Но я встречался с историей когда один багфикс ломал напрочь нечто в совершенно другой стороне. А так перед релизом прогнать, шобы все галочки были, оно как-то спокойней.

← →
Суслик_ (2009-08-26 18:40) [12]

Имхо, Паша, на это специательный человек нужен. Программист такое не потянет в параллель с основной работой. Т.е. тесты то программист будет писать (скорее всего), но под чутким руководством начальника контроля качества. Иначе можно в паранойю впасть - тестировать команду I := 1. А присвоилось ли? Утрирую, конечно. Но профессиональный человек (под профессионалом я понимаю не навык, а роль - профессиональный тестер) лучше определит те области, где нужно поднажать в регрессивных тестах, а на что можно "забить".

Я тебя нисколько не отговариваю, но я думаю, что перед принятием решения о применении тестов в своей работе нужно почитать апологетов этого направления. Вот Бэк вроде очень любит это дело. Т.е. поднабраться опыта нужно и выяснить будущие подводные камни.

← →
Игорь Шевченко © (2009-08-26 18:47) [13]

Суслик_ (26.08.09 18:40) [12]

Ты Бека тоже не читал ?

← →
Суслик_ (2009-08-26 18:58) [14]

Читал, но давно. Для меня это тогда было мало понятно, и мало что отложилось.
Кроме парадигмы "разработка через тесты" - т.е. сначала тесты, потом разработка. Все собираюсь перечитать, но никак глаза не дойдут.

← →
Игорь Шевченко © (2009-08-26 19:04) [15]

Суслик_ (26.08.09 18:58) [14]

> Читал, но давно

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

← →
Суслик_ (2009-08-27 00:47) [16]

Игорь. Бек-беком, а я тебе сказал практику своего использования. Ентузязм у меня был где-то почти год - делал как регрессивные тесты, так и тесты-ТЗ (потом под них писал). Тогда у нас народу было больше - все делали тесты. Но в итоге без должной организации (а я уже сказал, что хороший уровень организации и не имхо может только спец. человек обеспечить - сука такая, который только и ждет, что заставить тебя делать лишнюю работу) вся завяло. Тесты, однако, иногда гоняются.

← →
pasha_golub © (2009-08-27 13:48) [17]

Ну, видимо ясно, что не панацея все это. Но встряска организму не помешает :)

← →
iZEN (2009-08-27 15:08) [18]

Читайте: Д.Месарош "Шаблоны тестирования xUnit".

← →
iZEN (2009-08-27 15:23) [19]

> Суслик_ (27.08.09 00:47) [16]
>
> Игорь. Бек-беком, а я тебе сказал практику своего использования.
> Ентузязм у меня был где-то почти год - делал как регрессивные
> тесты, так и тесты-ТЗ (потом под них писал). Тогда у нас
> народу было больше - все делали тесты. Но в итоге без должной
> организации (а я уже сказал, что хороший уровень организации
> и не имхо может только спец. человек обеспечить - сука такая,
> который только и ждет, что заставить тебя делать лишнюю
> работу) вся завяло. Тесты, однако, иногда гоняются.

А вы попробуйте СНАЧАЛА писать тесты, а ПОТОМ писать код.

Сейчас наметился переход к парадигме Example-Driven Architecture, когда рабочий код пишется на основе работающих "примеров".

В этом случае:
1) Тесты являются примерами и документируют спецификацию на программный продукт.
2) Тесты пишутся по-одному за раз, иногда пишется фреймворк для будущих тестов.
3) Разработка "извне во внутрь" — последующие тесты определяются пройденными предыдущими (слоями).
4) Делается проверка состояний (State Verification), но иногда и проверка поведения (Behavior Verification) кода.
5) Тестовая конфигурация для каждого теста своя! (о чём жалеет разработчик NUnit)
6) Для СУБД, насколько это возможно, используется СУБД, целиком работающая в памяти — меньше накладных расходов на ввод/вывод диска.
7) Для командной разработки используется не кластер, а сервер тестирования с механизмом синхронизации рабочих пространств разработчиков — все тесты выполняются на нём, а отчёты идут разработчику, который запустил тесты в "своём" пространстве. При этом разработчик может продолжать работать, ожидая результатов тестов.

← →
Суслик_ (2009-08-27 16:33) [20]

Ув, iZEN.

1) Вы, видимо, не до конца прочитали мои слова - я делал и до и после.
2) При изложении ваших 7 пунктов Вы только подтвержаете мои слова - для тестирования нужен специательный человек в команде, который будет поддерживать данную архитектуру, возможно, совмещая это с работой программистом.

← →
Kolan © (2009-08-30 10:42) [21]

Ребята, а на английском Кента Бека по сабжу ни у кого нет?

← →
Жорж (2009-08-30 15:38) [22]

> Игорь Шевченко © (24.08.09 13:35) [1]
>
> 1. Стандартов никаких нет
> 2. Ты можешь делать все, как считаешь нужным, но у DUnit
> система следующая: setup теста, тест, teardown теста. Что
> внутри теста находится - на совести разработчика.
>
> У меня в одном из тестов в setup поднимается база из дампа
> :)
>

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

← →
Игорь Шевченко © (2009-08-30 15:56) [23]

Жорж (30.08.09 15:38) [22]

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

← →
Суслик_ (2009-08-30 17:59) [24]

2Игорь

Если не храните в CVS, то как обмениваетесь тогда тестами?
Или у каждого свой личный набор тестов?

> то как обмениваетесь тогда тестами?

С кем ?

← →
Суслик_ (2009-08-30 20:07) [26]

>> С кем?

Например, с ответственным за тестирование. Должен же быть такой, пусть и разработчик. Или у вас каждый свою область тестирует сам?

Суслик_ (30.08.09 20:07) [26]

Я извиняюсь, но юнит-тесты - это вообще-то часть процесса сборки. Нафига при этом с кем-то меняться, да еще и при помощи CVS, я не понимаю

А мне вот интересно... Как этими тестами пользоваться? Посмотрел... решил, что мне это нафиг не надо.. Но вот кто-то пользуется.. Объясните, зачем и как, если не трудно.

← →
Суслик_ (2009-08-30 21:09) [29]

2Игорь

Т.е. ты пользуешься своими тестами только сам?

Суслик_ (30.08.09 21:09) [29]

Сборка и выполнение тестов - это часть процесса общей сборки. Я даже сам не пользуюсь. Все желающие могут выполнить тест после сборки в любой момент, дополнительно к автоматическому выполнению.

← →
Суслик_ (2009-08-30 22:37) [31]

2Игорь.

Не понял, но хочу понять.

Ты говоришь, что тесты не лежат в репозитари. Они лежат рядом с иходниками, который, очевидно, лежат в репозитарии. Верно?
Собсно вопросы
1. Вот ты написал тест. Куда ты его кладешь, если не в репозитарий?
2. Пришел к тебе новый человек, тебе нужно дать ему исходники. Как он получает исходники тестов, если их нет в репозитарии?

Я бы нашел на эти вопросы ответы сам, если бы ты не сказал, что тесты лежат вместе с боевыми модулями. Например, у вас может быть отдельный склад тестов, пусть без соурконтрола, туда все тесты и кладут. А если рядом с боевыми модулями, то я не понимаю как это.

Суслик_ (30.08.09 22:37) [31]

Пост [23]: "Тестовые данные в репозитарии не хранятся. Сами модули тестов хранятся, в том же месте, где и боевые модули".

Боевые модули хранятся в системе контроля версий.

Во время сборки тестовые модули вынимаются из репозитария, вместе с основными, собираются основные приложения, собираются тесты, запускаются. Если им нужны какие-то внешние специальные данные, они хранятся во вполне определенном месте.

← →
Суслик_ (2009-08-31 00:28) [33]

> Игорь Шевченко © (31.08.09 00:14) [32]

А, шорт побъери. Игорь, извиняй. Не понял тебя, виноват. Конечно, все верно.

Спасибо за терпение в объяснении!

> Суслик_ (31.08.09 00:28) [33]

> А, шорт побъери. Игорь, извиняй. Не понял тебя, виноват.

Я точно так же не понял. :)) Эпистолярный жанр однако.

> Kolan © (30.08.09 10:42) [21]
>
> Ребята, а на английском Кента Бека по сабжу ни у кого нет?
>

А на русском есть?

На русском есть на torrenst.ru. Сильно не советую, перевод... капец.

Unit tests. Советы требуются Найти похожие ветки