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

Question

Просто поиск в Google 'TDD' и 'GWT' легко приводит к этой статье , где автор объяснил, как он может протестировать приложение GWT без контейнера. Тем не менее, я думаю, что его пример не основан на тестировании, так как он сначала разрабатывает весь проект, а затем пишет тест, а не «сначала тест».

Это заставляет меня задуматься: можно ли разрабатывать тестирование в первую очередь на пользовательском интерфейсе, таком как GWT? Некоторые люди говорят, что код пользовательского интерфейса не подходит для TDD. Но я думаю, что, приняв паттерн MVC, мы можем хотя бы протестировать MC-часть? (таким образом, V - это часть пользовательского интерфейса, которая не может быть разработана на основе тестирования).

Каким будет первый провальный тест, который мы напишем на примере статьи?

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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