Каков наилучший инструмент тестирования для Swing-приложений?

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

Каков ваш предпочтительный инструмент для тестирования модулей для тестирования приложений Swing? Почему вам это нравится?

Ответ 1

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

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

Ответ 2

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

Мне была поручена автоматизация приложения с несколькими чрезвычайно сложными пользовательскими компонентами, написанными внутри компании с нуля. Я прошел процесс обзора, который длился два месяца, в котором я принял решение о том, какой инструмент для тестирования использовать, из списка, имеющего около 30 доступных инструментов тестирования, как коммерческих, так и FOSS.

Это был единственный тестовый инструмент, который смог успешно автоматизировать наши особые пользовательские компоненты; где IBM Rational Functional Tester, MicroPocus TestPartner, QF-Test, Abbot и FEST не удалось.

С тех пор мне удалось успешно интегрировать тесты с Cruise Control, чтобы они запускались после завершения каждой сборки приложения.

Слово предупреждения, хотя:
1) он довольно грубый по краям в способе обработки JTables. Я обошел это, написав для них свой собственный класс прокси.
2) Пока не поддерживает запись/повтор действий перетаскивания.

Ответ 3

Рассмотрим марафон (http://www.marathontesting.com/Home.html)--tests написаны в Jython, поэтому легко писать любые типы предикатов на основе состояния объекта.

Ответ 4

У меня была возможность поиграть с QF-TEST один раз. Он коммерческий, но предлагает много функциональности. Возможно, вы посмотрите на это: http://www.qftest.de/en/index.html

Ответ 5

Вы можете попытаться использовать Cucumber и Swinger для написания функциональных приемочных тестов на простом английском языке для приложений GUI Swing. Swinger использует библиотеку Netbeans Jemmy под капотом, чтобы управлять приложением.

Cucumber позволяет писать тесты следующим образом:

 Scenario: Dialog manipulation
    Given the frame "SwingSet" is visible
      And the frame "SwingSet" is the container
    When I click the menu "File/About"
    Then I should see the dialog "About Swing!"
    Given the dialog "About Swing!" is the container
    When I click the button "OK"
    Then I should not see the dialog "About Swing!"

Посмотрите на это видеоролик Swinger, чтобы увидеть его в действии.

Ответ 6

Я очень рекомендую QFTest. Я использовал его для своего коммерческого продукта, и он отлично работает с почти нулевым кодом (для некоторых приложений мне нужно использовать API-интерфейсы java для некоторых вещей). Он отлично справляется с идентификацией компонентов swing и довольно толерантен к обновлениям вашего графического интерфейса - (изменение размера, перепозиционирование и добавление компонентов не нарушают существующие тесты). Я сделал основные обновления для функциональности и мои тесты все еще работают.

Это дорого, но я думаю, что он уйдет через пару месяцев.

Перед тем, как QFTest попытался:

1) Automatedqa - хороший инструмент, но окна ориентированы и не понимают Swing. Как и Quick Test Pro.

2) UISpec4J. После того, как я посвятил ему целую 50-часовую неделю, у меня были проблемы с хрупкостью и загадочным кодом Java. Использование его было слишком сложным - попытка отладки/обновления сотен строк java, выполняющих последовательность из дюжины графических интерфейсов, просто не работала для моего мозга. Я закончил тем, что избегал писать тесты, потому что это намного сложнее, чем собственно писать приложение!

Ответ 8

Мне нравится Jemmy, библиотека, написанная для тестирования Netbeans.

Ответ 9

Не ответ, а уточнение.

Запись и воспроизведение - это не то, что нужно. Команды должны иметь возможность писать тесты до того, как код был написан. В противном случае кодеры завершают свою работу и ждут, пока тестеры скремблируются, чтобы записывать тесты (прерванные исправлениями при обнаружении проблем).

В настройке BDD/TDD/ATDD вам действительно нужен какой-то инструмент, который позволяет вам тестировать script для кода, который еще не написан, с указанием имен элементов пользовательского интерфейса и т.п.

Существуют ли инструменты, которые работают для тестирования без водопада?