Многие критикуют тестирование пользовательского интерфейса и в качестве довода приводят медленность и постоянное его изменение, особенно на старте проекта. Тут надо различать виды тестирования, т.к. тестирование пользовательского интерфейса можно разделить на два направления:
- Тестирование логики GUI;
- Тестирование бизнес — логики и её реакции на пользовательские входные данные.
Архитектура UI и её тестируемость
Далее хочется остановиться подробнее на широко используемом паттерне проектирования UI, а именно на Model-View-View-Model (MVVM).
Кратко о MVVM
Паттерн MVVM позволяет разделить логику представления (которая определяет, какая информация отображается на экране) от фактического представления (которое определяет, как отображается информация). Схематически картина выглядит следующим образом:
View(представление) — это пользовательский интерфейс, который состоит из текстовых полей, лэйблов, кнопоки и т.д. Оно отвечает за формирование структуры расположения видимых на экране элементов. Model(модель) представляет собой реализацию модели предметной области, в основном она состоит из модели данных наряду с бизнес-правилами и логикой валидации. View – Model является посредником между представлением и моделью, обрабатывает действия пользователя (например, нажатие кнопки) и взаимодействует с моделью по средствам вызова методов из класса определённой модели (для обновления или добавления записи в базе данных). Также View-Model отвечает и за предоставление данных (выполняет запросы и передаёт их результаты в представление).
Одной из ключевых идей, лежащих в MVVM и других архитектурах пользовательского интерфейса, таких как Model-View-Controller (MVC) и Model-View-Presenter (MVP), является то, что в данных архитектурах происходит разделение задач, что делает их хорошо тестируемыми с помощью unit — тестов, вместо того, чтобы каждый раз проводить end-to-end тестирование.
Тестирование пользовательских интерфейсов построенных на MVVM
Так как вся бизнес — логика содержится в модели представления, то имеет смысл сделать её главной целью нашего тестирования. Так как вьюмодели реализованы в виде классов в объектно-ориентированных языках программирования, то и тестировать их можно с помощью unit тестов.
Более сложное взаимодействие между несколькими моделями можно протестировать с помощью автотестов. Если модель обращается к какому-либо API или сервису, то задача вообще упрощается на порядок. Также можно использовать mock-контейнеры для эмуляции БД. Такой подход эффективен, когда нужно протестировать только логику приложения, и нет чётких требований, что все тесты должны быть через UI и не тестируется сам интерфейс и расположение на нём элементов. По сравнению со скоростью тестов с применением Selenium, тестирование только view – model происходит гораздо быстрее.
