DUnit
 

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

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

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

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

Ответ: DUnit
 

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

Ответ: DUnit
 

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

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

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

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

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