Вычисления в моем коде хорошо проверены, но из-за большого количества графического кода мой общий охват кода ниже, чем хотелось бы. Существуют ли какие-либо рекомендации по унифицированному графическому интерфейсу? Это даже имеет смысл?
Например, в моем приложении есть графики. Мне не удалось выяснить, как автоматизировать тестирование графиков. Для проверки правильности графика требуется человеческий глаз, AFAIK.
(Я использую Java Swing)
Такие конструкции, как MVP и MVC, обычно пытаются абстрагировать как можно больше логики от реального графического интерфейса. Одна очень популярная статья об этом - "Диалоговое окно смирения" Майкла Фезерса. Лично у меня был неоднозначный опыт с попыткой вывести логику из пользовательского интерфейса - иногда это работало очень хорошо, а иногда это было больше проблем, чем оно того стоило. Это несколько за пределами моей области знаний, хотя.
Конечно, ответ заключается в использовании MVC и максимально возможной логике из графического интерфейса.
Сказано, что я давно слышал от коллеги, что, когда SGI портировал OpenGL на новое оборудование, у них была куча модульных тестов, которые нарисовали бы набор примитивов на экране, а затем вычислили сумму MD5 кадровый буфер. Это значение затем можно сравнить с известными хорошими хеш-значениями, чтобы быстро определить, соответствует ли API на пиксель.
Вы можете попробовать UISpec4J - библиотеку функционального и/или модульного тестирования с открытым исходным кодом для Java-приложений на основе Swing...
Вот несколько советов:
Попробуйте удалить большинство кода из GUI (иметь контроллер и объект модели) таким образом, вы сможете протестировать их без GUI.
Для графики вы должны проверить значение, которое вы подаете на код, который генерирует графику.
Вы можете попробовать использовать Cucumber и Swinger для написания функциональных приемочных тестов на простом английском языке для приложений Swing GUI. 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, чтобы увидеть его в действии.
Существует Selenium RC, который будет автоматизировать тестирование веб-интерфейса. Он будет записывать действия и воспроизводить их. Вам все еще нужно будет пройти через взаимодействие с вашим пользовательским интерфейсом, так что это не поможет с покрытием, но может использоваться для автоматизированных сборок.
Тестирование - это художественная форма. Я согласен, что логика должна быть максимально удалена из графического интерфейса. Затем мы можем сосредоточить наше подразделение на тестировании. Как и все остальное, тестирование связано с уменьшением риска. Вам не всегда нужно проверять все, но много раз лучше всего разбить различные тесты в разных областях.
Другой вопрос - что вы действительно пытаетесь протестировать на уровне пользовательского интерфейса. Тестирование пользовательского интерфейса является самым дорогим тестированием, потому что обычно требуется больше времени для создания, обслуживания и наиболее хрупкого. Если вы проверите логику, чтобы знать, что координаты правильные, прежде чем пытаться провести линию, что вы тестируете конкретно? Если вы хотите проверить график с красной линией, нарисован. Можете ли вы дать ему заданные координаты и проверить, являются ли определенные пиксели красными или не красными? Как было предложено выше, сравнение растровых изображений работает, Selenium, но мой основной упор будет заключаться в том, чтобы не тестировать графический интерфейс, а скорее проверять логику, которая поможет создать пользовательский интерфейс, а затем сосредоточиться на том, какая часть пользовательского интерфейса ломается или подозревается, и сосредоточить несколько тестов есть.
Вы можете использовать JFCUnit, чтобы проверить свой графический интерфейс, но графика может быть более сложной. Я несколько раз делал снимки своего графического интерфейса и автоматически сравнивал его с предыдущей версией. Хотя это не дает фактического теста, оно предупреждает вас, если автоматическая сборка не дает ожидаемого результата.
Из вашего вопроса я собираюсь понять, что вы ищете автоматизированный способ проверки поведения вашего GUI в деталях, пример, который вы даете, - это проверка правильности рисования кривой.
Механизмы модульного тестирования обеспечивают способ автоматического тестирования, но я думаю, что те тесты, которые вы хотите сделать, - это сложные интеграционные тесты, которые проверяют правильное поведение множества классов, среди которых классы вашего инструментария/библиотеки GUI, которые вы не должны тестировать.
Ваши параметры сильно зависят от того, какие платформы/инструментальные средства/фреймворки вы используете: например, приложение, использующее Qt в качестве своей инфраструктуры графического интерфейса, может использовать Squish для автоматизации своих тестов. Вы проверяете результаты своих тестов один раз, и последующие автоматически выполняемые тесты сравнивают результаты с проверенными результатами.
Window Licker для Swing и Ajax
Из того, что я знаю, это довольно сложно и действительно зависит от языка. У многих языков есть собственный способ тестирования графического интерфейса, но если вам действительно нужно протестировать GUI (в отличие от взаимодействия модели /gui ), вы часто приходится имитировать фактические кнопки нажатия на пользователя. Например, среда SWT, используемая в Eclipse, обеспечивает SWTBot, JFCUnit, Mozilla имеет собственный способ имитации этого в XUL (и из того, что я читал в своих блогах, эти тесты кажутся довольно хрупкими).
Иногда вам нужно сделать снимок экрана и проверить идеальный рендеринг пикселей (я считаю, что Mozilla делает это для проверки корректно отображаемых страниц) - для этого требуется более длинная настройка, но может быть то, что вам нужно для графиков. Таким образом, когда вы обновляете свой код и тестовые перерывы, вам нужно вручную проверить изображение, если сбой был реальным, или вы улучшили код рендеринга графа для создания более красивых графиков и вам нужно обновить скриншоты.
Если вы используете Swing, FEST-Swing полезен для вождения вашего GUI и утверждений о тестировании. Это довольно просто проверить такие вещи, как "если я нажму кнопку A, появится диалоговое окно B" или "если я выберу вариант 2 из раскрывающегося списка, все флажки должны быть отменены".
Сценарий графика, который вы упомянули, не так просто проверить. Очень легко получить покрытие кода для компонентов GUI, просто создав и отобразив их (и, возможно, запустив их с помощью FEST). Однако принятие значимых утверждений является трудной частью (и охват кода без значимых утверждений - упражнение в самообмане). Как вы проверяете, что график не был перевернут или слишком мал?
Я думаю, что вам просто нужно признать, что некоторые аспекты графических интерфейсов не могут быть эффективно протестированы с помощью автоматических модульных тестов и что вам придется тестировать их другими способами.
Это не ваша работа, чтобы проверить библиотеку GUI. Таким образом, вы можете избежать ответственности за проверку того, что на самом деле нарисовано на экране, и вместо этого проверить свойства виджетов, доверяя библиотеке, что они точно представляют то, что нарисовано.