Pull to refresh

Martin Fowler — GUI Architectures. Часть 5

Reading time 4 min
Views 6.6K
Предыдущая часть здесь. Оригинал статьи здесь.

Это последняя часть.

Humble View (простое представление)


Несколько лет назад в сфере программирования появилось новое модное веяние — писать самотестируемый код. Несмотря на то, что я являюсь последним человеком, к которому следует обращаться по вопросам моды, я целиком погрузился в эту идею. К тому же, среди моих коллег есть много фанатов xUnit каркасов, автоматических регрессионных тестов, методик Test-Driven Developement, Continious Integration и прочих подобных непонятных терминов.

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

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

Решением описанной проблемы является такой дизайн пользовательских интерфейсов, где минимизируется количество функционала для труднотестируемых объектов. Этот подход четко описал Michael Feathers в своей работе The Humble Dialog Box. Gerard Meszaros обобщает это понимание в идею простого объекта (Humble Object) — любой объект, который сложно протестировать, должен обладать минимумом функционала. Тем самым, если нам не удастся создать тесты для такого объекта, шансы получить ошибку в его поведении так же минимизируются.

В работе The Humble Dialog Box используется presenter из модели MVP. Однако, он обладает гораздо большими возможностями, чем тот, что описан в базовом MVP. Presenter не только определяет, как реагировать на события, но и занимается наполнением данными в пользовательских элементах. В результате, получается, что пользовательским элементам больше нет нужды иметь доступ и обозревать модель. Они формируют пассивное представление (Passive View), которое целиком управляется через presenter.

Описанный подход не единственный, которым можно сделать представление простым. Другой подход — использовать шаблон модели представления (Presentation Model). Его маленьким минусом является то, что элементам управления нужно будет придать больше функционала, который позволит им привязаться (map) к модели представления.

Ключем в обоих подходах является то, что тесты приходится писать только для presenter-а или модели представления. В них тестируется основной «рисковый» функционал, а сами «сложнотестируемые» элементы управления остаются в стороне.

Подробнее о модели представления. Модель представления должна реализовывать всю значимую логику. Все пользовательские события должны перенаправляться в модель представления. Все, что нужно сделать элементам управления — это привязаться к ее соответствующим свойствам. Тесты будут тестировать весь функционал модели представления без необходимости присутствия какого-либо элемента управления. Единственный риск остается только в самой привязке элементов к модели. Если учесть, что функционал привязки очень прост в реализации, можно закрыть его тестирование глаза. Правда, в этом случае, представление не такое «простое», как могло бы быть в подходе Passive View. Однако, разница очень мала.

В случае с пассивным представлением (Passive View), как я уже сказал, отсутствие функционала привязки убирает риск, который присутствует в случае с моделью представления. Цена отсутствия этого риска заключается в необходимости двойного тестирования (Test Double), которое нужно, чтобы проэмулировать поведение экрана во время выполнения тестов. Это значит, что нужно будет создавать и настраивать какой-то дополнительный программный механизм.

Похожее решение присутствует и в шаблоне Supervising Controller. Некоторый риск возникновения ошибки возникает тогда, когда представление вынуждено заниматься привязкой (как в случае с моделью представления (Presentation Model). Преимущество такой привязки, кстати, состоит в том, что вся она является декларативной. Количество таких привязок при Supervising Controller будет меньше, чем в модели представления, поскольку Supervising Controller занимается передачей данных (в самых сложных случаях и сценариях) к элементам управления в явном виде, определенном в его коде, тогда как модель представления вынуждена решать свои сложные сценарии через механизм привязок.

Далее


Если вы хотите прочитать статьи, в которых развиваются описанные идеи, проверьте мой bliki

Благодарности


Василий Быков щедро поделился со мной своей копией Hobbes — имплементацией платформы Smalltalk 80 версии 2 (1980 годы!), которую можно запустить на современной версии VisualWorks. В этой копии я смог создать примеры на живом, оригинальном MVC, что мне очень помогло понять, как он работал и использовался в те времена. Кстати, много людей негативно воспринимают использование виртуальных машин. Интересно, чтобы они сказали, если бы увидели, как я работаю в Smalltalk 80 на виртуальной машине, написанной в VisualWorks, которая работает на виртуальной машине VisualWorks, которая работает на Windows XP, которая запущена в VMware, которая запущена в Ubuntu?

Значительные редакции


18-ое июля 2006 года: первая публикация на сайте

Все права принадлежат Мартину Фаулеру (Martin Fowler). Все права защищены.
Tags:
Hubs:
+9
Comments 17
Comments Comments 17

Articles