Как я могу тестировать графический интерфейс?

Такие проекты, как MVP и MVC, как правило, стараются максимально абстрагировать логику из фактического GUI. Одна очень популярная статья об этом – «Скромный диалог» Майкла Перса. Лично у меня был смешанный опыт с попыткой вывести логику из пользовательского интерфейса – иногда это очень хорошо работало, а в других случаях было больше проблем, чем того стоит. Тем не менее, это вне моей компетенции.

Разумеется, ответ заключается в использовании MVC и максимально возможной логике из графического интерфейса.

Это было сказано, что я давно слышал от коллеги, что, когда SGI переносит OpenGL на новое оборудование, у них была куча модульных тестов, которые нарисовали набор примитивов на экране, а затем вычислили сумму MD5 буфера кадров. Это значение затем можно сравнить с известными хорошими hash-значениями, чтобы быстро определить, соответствует ли API на пиксель.

Вы можете попробовать UISpec4J – это функциональная и / или модульная тестовая библиотека с открытым исходным кодом для Java-приложений Swing …

Вот несколько советов:

Попытайтесь удалить большинство кода из GUI (иметь controller и объект модели) таким образом, вы сможете протестировать их без GUI.

Для графики вы должны проверить значение, которое вы подаете на код, который генерирует графику.

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

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

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

Взгляните на демоверсию Swinger, чтобы увидеть ее в действии.

Существует Selenium RC , который будет автоматизировать тестирование веб-интерфейса. Он будет записывать действия и воспроизводить их. Вам все равно нужно пройти через взаимодействие с вашим пользовательским интерфейсом, так что это не поможет в освещении, но оно может быть использовано для автоматических сборок.

Тестирование – это художественная форма. Я согласен, что логика должна быть максимально удалена из графического интерфейса. Затем мы можем сосредоточить наше подразделение на тестировании. Как и все остальное, тестирование связано с уменьшением риска. Вам не всегда нужно проверять все, но много раз лучше всего разбить различные тесты в разных областях.

Другой вопрос – что вы действительно пытаетесь протестировать на уровне пользовательского интерфейса. Тестирование пользовательского интерфейса является самым дорогим тестированием, потому что обычно требуется больше времени для создания, обслуживания и наиболее хрупкого. Если вы проверите логику, чтобы знать, что координаты правильные, прежде чем пытаться провести линию, что вы тестируете конкретно? Если вы хотите проверить график с красной линией, нарисован. Можете ли вы дать ему заданные координаты и проверить, являются ли определенные пиксели красными или не красными? Как было предложено выше, сравнение растровых изображений работает, Selenium, но мой основной упор будет заключаться в том, чтобы не тестировать графический интерфейс, а скорее проверять логику, которая поможет создать пользовательский интерфейс, а затем сосредоточиться на том, какая часть пользовательского интерфейса ломается или подозревается, и сосредоточить несколько тестов там.

Вы можете использовать JFCUnit для тестирования вашего графического интерфейса, но графика может быть более сложной. Я несколько раз делал снимки своего графического интерфейса и автоматически сравнивал его с предыдущей версией. Хотя это не дает фактического теста, оно предупреждает вас, если автоматическая assembly не позволяет получить ожидаемый результат.

Из вашего вопроса я собираюсь понять, что вы ищете автоматизированный способ тестирования поведения вашего GUI в деталях, пример, который вы даете, – это проверка правильности рисования кривой.

Структуры модульного тестирования обеспечивают способ автоматического тестирования, но я думаю, что те тесты, которые вы хотите сделать, – это сложные интеграционные тесты, которые проверяют правильное поведение множества classов, среди которых classы вашего инструментария / библиотеки GUI, которые вы не должны испытывать.

Ваши варианты сильно зависят от того, какие платформы / инструментальные средства / фреймворки вы используете: например, приложение, использующее Qt в качестве своей инфраструктуры графического интерфейса, может использовать Squish для автоматизации своих тестов. Вы проверяете результаты своих тестов один раз, и последующие автоматически выполняемые тесты сравнивают результаты с проверенными результатами.

Окно Licker для Swing & Ajax

Из того, что я знаю, это довольно сложно и действительно зависит от языка: у многих языков есть свой собственный способ тестирования графического интерфейса, но если вам действительно нужно протестировать GUI (в отличие от взаимодействия модели / gui), вам часто приходится имитировать фактические кнопки нажатия пользователем. Например, среда SWT, используемая в Eclipse, предоставляет SWTBot , JFCUnit уже упоминался, Mozilla имеет собственный способ имитации этого в XUL (и из того, что я читал в своих блогах, эти тесты кажутся довольно хрупкими).

Иногда вам нужно сделать снимок экрана и проверить идеальный рендеринг пикселей (я считаю, что Mozilla делает это для проверки корректно отображаемых страниц) – для этого требуется более длинная настройка, но может быть то, что вам нужно для графиков. Таким образом, когда вы обновляете свой код и тестовые перерывы, вам нужно вручную проверить изображение, если сбой был реальным, или вы улучшили код рендеринга графа, чтобы генерировать более красивые графики и вам нужно обновить скриншоты.

Если вы используете Swing, FEST-Swing полезен для вождения вашего GUI и тестирования. Это довольно просто проверить такие вещи, как «если я нажму кнопку А, появится диалоговое окно B» или «если я выберу вариант 2 из раскрывающегося списка, все флажки должны быть отменены» .

Сценарий графика, который вы упомянули, не так-то просто проверить. Довольно легко получить покрытие кода для компонентов GUI, просто создав и отобразив их (и, возможно, запустив их с помощью FEST). Однако принятие значимых утверждений является трудной частью (и охват кода без значимых утверждений – упражнение в самообмане). Как вы проверяете, что график не был перевернут или слишком мал?

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