Каков наилучший инструмент тестирования для 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, выполняющих последовательность из дюжины графических интерфейсов, просто не работала для моего мозга. Я закончил тем, что избегал писать тесты, потому что это намного сложнее, чем собственно писать приложение!
Ответ 7
попробуйте pounder: http://pounder.sourceforge.net/
Ответ 8
Мне нравится Jemmy, библиотека, написанная для тестирования Netbeans.
Ответ 9
Не ответ, а уточнение.
Запись и воспроизведение - это не то, что нужно. Команды должны иметь возможность писать тесты до того, как код был написан. В противном случае кодеры завершают свою работу и ждут, пока тестеры скремблируются, чтобы записывать тесты (прерванные исправлениями при обнаружении проблем).
В настройке BDD/TDD/ATDD вам действительно нужен какой-то инструмент, который позволяет вам тестировать script для кода, который еще не написан, с указанием имен элементов пользовательского интерфейса и т.п.
Существуют ли инструменты, которые работают для тестирования без водопада?