Как протестировать разработку GWT?

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

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

Этот метод, вероятно, лучше всего описал Майкл Фезерс несколько лет назад в статье, озаглавленной "Диалоговое окно Humble". ". Это также основная идея шаблона Model-View-Presenter, который четыре года вызывал такой ажиотаж. тому назад; и теперь разделен на шаблоны Passive View и Supervising Controller. Ссылка на статью в этом вопросе использует эти идеи, но в виде теста после, а не через тестирование.

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

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

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

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

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

Я успешно протестировал разработку приложений Swing и GWT через графический интерфейс.

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

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

У GWT есть хуки, чтобы помочь с этим. Вам необходимо установить идентификаторы отладки в виджетах GWT и импортировать модуль DebugID в ваше приложение. Затем ваши тесты могут взаимодействовать с приложением, управляя веб-браузером, находя элементы по их идентификатору и нажимая на них или вводя в них текст. веб-драйвер — очень хороший API для этого.

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

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

• Цели пользователя: тесты проверяют, может ли пользователь достичь своих целей с помощью системы, и демонстрируют, как эти цели достигаются с помощью последовательности...
• Действия пользователя: то, что пользователь делает через графический интерфейс, представленный в виде драйверов, которые выполняют...
• Жесты: низкоуровневая мышь и ввод с клавиатуры для управления графическим интерфейсом.

Эта иерархия часто используется в литературе по дизайну, ориентированному на пользователя (хотя и с другой терминологией).