DUnit

krot89 · 26.04.2008, 12:49

Интересно, кто-нибудь здесь серъёзно занимается тестированием при помощи DUnit или другой автоматизации?

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

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

Что хотелось бы:
- Обсудить что можно ещё тестить.
- обсудить/обменяться универсальными тестами.
- Обсудить облегчение труда по написанию специфических тестов

Dmitry_Ukr · 04.05.2008, 10:02

Я думаю, что DUnit не стоит использовать для таких целей, как проверка именования компонентов и целостность UI.
Для наименование компонентов легче использовать одно соглашение по наименованию компонентов, классов, процедур, функций.
ЮИ можно прогнать тестами типа Rational Robot.
Да и вообще лучше разделить функциональное тестирование и модульное.
Функциональным пусть занимается тестер с Robot'ом, а модульные пусть пишет программист. Модульные должны гарантировать, что программист не допустил ошибок в логике работы алгоритмов. Т.е. имея заведомо правильные и неправильные входные данные, программист пишет тест, который передает эти данные в некоторую функцию и получает результат сверяет его с эталонным. Внутри теста проходит сравнение и выдается результат. Например функция проверки пользователя, при неправильной имени и пароле будет генерировать fail, при правильном - pass. Заодно будем проверяться сможет ли вообще корректно сработать эта функция, не происходит ли внутри нее исключения.
P.S. И не надо писать тест на каждый маломальскую иконку или кнопочку, берите более крупно. Проверяйте логику.

krot89 · 04.05.2008, 12:45

Rational Robot - Инструмент для автоматизации записи и воспроизведения сценариев тестов. Сценарии тестов записываются на специальном языке программирования и могут быть получены либо автоматически (путем записи действий пользователя при
работе с системой), либо вручную.

OpenCTF (надстройка к DUnit) - прекрасно решает вопросы:
- тестирование именования компонентов. (не нарушил ли кто правила именования, нету ли "лишних" компонент и т.п.)
- тестирование отдельных свойств компонентов. (например dataSourse у тех у кого он есть, hint у кнопок и т.п.)
Есть готовые интерфейсы, примеры и тесты.
На создание первого проекта-теста ушло где-то около дня. На второй проект я потратил уже около 10 минут.
Но это всё в рамках модульного тестирования. Просто делается "универсальный тест" Вернее 10000 тестов отдим модулем.
Почему в рамках? Да потому что соглашение об именовании это правильно. Но я пишу не один, да и сам как показали тесты иногда забываюсь.

Далее. Читаем что делает RR. Вопрос - а почему это не тест юнита? Он, родимый. Только скрипт пишется/генерится не на каком-то новом птичьем языке, а на родном - том же что и приложение.

Про иконки и логику - я неправ в том что смешал мухи и котлеты. OpenCTF и кусок на его основе - теже юнитовые тесты для элементов интерфейса. Позволяет избегать мелких ошибок. Или отлавливать их массого.
Ещё ряд моих тестов интерфейса - RR нужно учить делать тоже самое (писать скрипт). Зачем? на делфях проще ;)
А вот нормального генератора я так и не нашёл. Чтоб мои щелчки мышью в скрипт превращал. Ещё много чего не нашёл. Ищу ;)

Ну и кстати RR денег стоит. А делфю я себе уже купил.

26.04.2008, 12:49	#1
krot89 Неактивный пользователь Пол: Регистрация: 17.01.2008 Сообщений: 27 Репутация: 4	DUnit Интересно, кто-нибудь здесь серъёзно занимается тестированием при помощи DUnit или другой автоматизации? Я пока освоил: - тестирование именования компонентов (очень полезно в больших проектах на пачку людей) - тестирование корректности маштабирования формы. - тестирование неизменности интерфейса. - тестирование формы на функциональность. Какие есть проблемы: - при тестировании на неизменность: -- мешается курсор клавиатуры (не умею прятать) -- фон под прозрачными формами (есть такие) -- не очень быстро - при тестировании формы на функциональность -- очень много приходится писать руками (т.е. для каждой формы пишешь пачку тестов). При её изменении - дописываешь/переписываешь эти тесты... Что хотелось бы: - Обсудить что можно ещё тестить. - обсудить/обменяться универсальными тестами. - Обсудить облегчение труда по написанию специфических тестов

04.05.2008, 10:02	#2
Dmitry_Ukr Неактивный пользователь Регистрация: 04.05.2008 Сообщений: 5 Репутация: 1	Ответ: DUnit Я думаю, что DUnit не стоит использовать для таких целей, как проверка именования компонентов и целостность UI. Для наименование компонентов легче использовать одно соглашение по наименованию компонентов, классов, процедур, функций. ЮИ можно прогнать тестами типа Rational Robot. Да и вообще лучше разделить функциональное тестирование и модульное. Функциональным пусть занимается тестер с Robot'ом, а модульные пусть пишет программист. Модульные должны гарантировать, что программист не допустил ошибок в логике работы алгоритмов. Т.е. имея заведомо правильные и неправильные входные данные, программист пишет тест, который передает эти данные в некоторую функцию и получает результат сверяет его с эталонным. Внутри теста проходит сравнение и выдается результат. Например функция проверки пользователя, при неправильной имени и пароле будет генерировать fail, при правильном - pass. Заодно будем проверяться сможет ли вообще корректно сработать эта функция, не происходит ли внутри нее исключения. P.S. И не надо писать тест на каждый маломальскую иконку или кнопочку, берите более крупно. Проверяйте логику.

04.05.2008, 12:45	#3
krot89 Неактивный пользователь Пол: Регистрация: 17.01.2008 Сообщений: 27 Репутация: 4	Ответ: DUnit Rational Robot - Инструмент для автоматизации записи и воспроизведения сценариев тестов. Сценарии тестов записываются на специальном языке программирования и могут быть получены либо автоматически (путем записи действий пользователя при работе с системой), либо вручную. OpenCTF (надстройка к DUnit) - прекрасно решает вопросы: - тестирование именования компонентов. (не нарушил ли кто правила именования, нету ли "лишних" компонент и т.п.) - тестирование отдельных свойств компонентов. (например dataSourse у тех у кого он есть, hint у кнопок и т.п.) Есть готовые интерфейсы, примеры и тесты. На создание первого проекта-теста ушло где-то около дня. На второй проект я потратил уже около 10 минут. Но это всё в рамках модульного тестирования. Просто делается "универсальный тест" Вернее 10000 тестов отдим модулем. Почему в рамках? Да потому что соглашение об именовании это правильно. Но я пишу не один, да и сам как показали тесты иногда забываюсь. Далее. Читаем что делает RR. Вопрос - а почему это не тест юнита? Он, родимый. Только скрипт пишется/генерится не на каком-то новом птичьем языке, а на родном - том же что и приложение. Про иконки и логику - я неправ в том что смешал мухи и котлеты. OpenCTF и кусок на его основе - теже юнитовые тесты для элементов интерфейса. Позволяет избегать мелких ошибок. Или отлавливать их массого. Ещё ряд моих тестов интерфейса - RR нужно учить делать тоже самое (писать скрипт). Зачем? на делфях проще ;) А вот нормального генератора я так и не нашёл. Чтоб мои щелчки мышью в скрипт превращал. Ещё много чего не нашёл. Ищу ;) Ну и кстати RR денег стоит. А делфю я себе уже купил.