Как я могу тестировать GUI?

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

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

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

Конечно, ответ должен использовать MVC и перемещение как можно больше логики из GUI.

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

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

Вот некоторые подсказки:

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

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

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

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

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

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

При использовании Swing , Swing ФЕСТИВАЛЯ полезен для управления GUI и тестирования утверждений. Это делает его довольно простым для тестирования вещей как , "если я нажимаю кнопку, диалоговое окно B должно быть отображено" или , "если я выбираю опцию 2 из выпадающего, все флажки должны стать невыбранными" .

сценарий графика, который Вы упоминаете, не настолько легко протестировать. Довольно легко получить покрытие кода для компонентов графического интерфейса пользователя только путем создания и отображения их (и возможно управления ими с ФЕСТИВАЛЕМ). Однако создание значимых утверждений является твердой частью (и покрытие кода без значимых утверждений является упражнением в самообмане). Как Вы тестируете это, график не был оттянут вверх тормашками или слишком маленький?

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

Мой подход к тестированию GUI развивается, как промышленное согласие. Но я думаю, что несколько ключевых методов начинают появляться.

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

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

2. Поблочное тестирование. Вы тесты записи на функции или небольшие единицы поведения GUI. Например, Ваши графики, возможно, должны вычислить различные оттенки цвета на основе 'основного' цвета. Можно извлечь это вычисление к функции и записать модульный тест на него. Можно искать логику как это в GUI (особенно допускающая повторное использование логика) и извлечь его в осторожные функции, которые могут быть более легко протестированной единицей. Даже сложное поведение может быть извлечено и протестировано этим способом †“, например, последовательность шагов в мастере может быть извлечена к функции, и модульный тест может проверить, что, учитывая вход корректный шаг возвращается.

3. проводник Компонента. Вы создаете экран 'проводника', чей только роль состоит в том, чтобы продемонстрировать каждый из допускающих повторное использование компонентов, которые составляют Ваш GUI. Этот экран дает Вам быстрый и простой способ визуально проверить, что каждый компонент имеет корректный взгляд & чувство. Проводник компонента более эффективен, чем ручное прохождение через Вашего целого приложения, потому что A) только необходимо проверить каждый компонент однажды и B) Вы не должны перейти глубоко в приложение для наблюдения компонента, можно просто просмотреть и сразу проверить его.

4. тестирование Автоматизации. Вы пишете тест, который взаимодействует с экраном или компонентом, моделируя щелчки мышью, ввод данных, и т.д., утверждая что прикладные функции правильно, учитывая эти манипуляции. Это может быть полезно как дополнительный тест резервного копирования, для получения потенциальных ошибок, которые могли бы пропустить другие тесты. Я склонен резервировать тестирование автоматизации на части GUI, которые наиболее подвержены к повреждению и/или очень очень важны. Части, где я хочу знать как можно раньше, повредилось ли что-то. Это могло включать очень сложные интерактивные компоненты, которые уязвимы для повреждения или важных основных экранов.

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

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

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

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

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

Это - все на основе моего личного опыта и исследования, а также большой рецензии на Тесты UI Ham Vocke .

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

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 , чтобы увидеть его в действии.

Окноочиститель для Swing & Ajax