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

Question

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

Например, в моем приложении есть графики.Я не смог понять, как автоматизировать тестирование графиков.Нужен человеческий глаз, AFAIK, чтобы проверить, верен ли график.

(Я использую Java Swing)

Answer 1

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

Вы можете попробовать использовать огурец и Swinger для написания функциональных приемочных тестов на английском языке для приложений Swing с графическим интерфейсом. Swinger использует библиотеку Джемми из 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 , чтобы увидеть его в действии.

Answer 6

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

Answer 7

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

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

Answer 8

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

Answer 9

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

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

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

Answer 10

Window Licker для Swing & amp; Ajax

Answer 11

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

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

Answer 12

Если вы используете Swing, FEST-Swing полезен для управления вашим графическим интерфейсом и проверка утверждений. Это довольно просто для тестирования таких вещей, как " если я нажимаю кнопку A, должно отображаться диалоговое окно B " или " если я выбираю вариант 2 из раскрывающегося списка, все флажки должен быть отменен " .

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

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

Answer 13

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