У меня был довольно неплохой опыт работы с Abbot и FEST , обе библиотеки с открытым исходным кодом для тестирования Swing UI.
Abbot, похоже, больше не поддерживается;в это было немного трудно войти, потому что рекордер не генерировал сценарии "достаточно хорошо".На самом деле, я использовал рекордер, чтобы «выучить» язык сценариев (теги XML), и, наконец, сам написал сценарии непосредственно с помощью простого текстового редактора.Это сработало довольно хорошо.
FEST использует другой подход, в котором вы должны кодировать (на Java) свои тесты пользовательского интерфейса.Это делает его инструментом, зарезервированным для разработчиков Java, тогда как Abbot может использоваться другими людьми (например, тестерами QA Team).
Основные проблемы с обоими инструментами и, возможно, с любым инструментом тестирования пользовательского интерфейса:
- , чтобы найти способ уникальной идентификации компонентов без использования их позиции или текстового содержимого (которое может меняться от одной ревизии к другой или затрудняет тестирование одного и того же приложения в другом
Locale) - до использовать правильное время в сценариях: эти инструменты тестирования могут запускать ваш пользовательский интерфейс намного быстрее, чем пользователь, поэтому ваш пользовательский интерфейс может быть недостаточно быстрым для них (например, можетпотребуется несколько десятков мсек, чтобы открыть диалоговое окно, и даже больше, чтобы заполнить таблицу из базы данных)
Для обеих проблем есть решение.
Для идентификации компонентов я настоятельносоветуем назвать все компоненты Swing (используя Component.setName()) в пользовательском интерфейсе и использовать для этого стратегию именования , которая может гарантировать, что никогда не будет 2 comкомпоненты с одинаковыми именами видны одновременно.В библиотеке guts-gui я даже разработал стратегию, которая автоматически называет компоненты Swing , которые хранятся в виде полей на панелях, это помогает добавлять имена компонентов после кодирования приложения.
Для синхронизации сценариев обе платформы принимают значение тайм-аута в ожидании появления диалога;Вы должны выбрать наилучшее значение, учитывая тот факт, что ваши тесты могут выполняться на разных типах машин с более или менее доступной мощностью.Вы должны использовать тайм-аут, который достаточно велик, чтобы скрипт не сообщал о ложных негативах (например, диалоговое окно, которое появляется через 1 секунду, тогда как скрипт ждет только 500 мс), но также не слишком долго, чтобы при наличии реальногоошибка (например, ожидаемый диалог никогда не появляется).Я предлагаю использовать время ожидания от 2 до 5 секунд, которое должно подходить для большинства платформ тестирования и большинства приложений.
Надеюсь, это поможет.