Модульные тесты обычно работают вызывая методы в интерфейсе тестируемого кода. Однако, при разработке пользовательского интерфейса, полноценное тестирование должно включать в себя нажатие кнопок и проверку появления соответствующих окон с правильным содержанием. Программируемые тесты пользовательского интерфейса (CUIT) – это автоматизированные тесты, проверяющие действия в пользовательском интерфейсе. Детальнее в теме MSDN Testing the User Interface with Automated Coded UI Tests.
Как создавать и использовать CUIT
Создание CUIT
Для того, чтобы создать программируемый тест пользовательского интерфейса, необходимо создать проект CUIT. В диалоговом окне New Project, опция создания CUIT находится под Visual Basic\Test или под Visual C#\Test. Если проект уже создан, в него нужно добавить новый программируемый тест пользовательского интерфейса.
Для записи теста, в диалоговом окне Generate Code нужно выбрать Record Actions. Окно Visual Studio минимизируется и в нижней правой части экрана появится рабочее окно для записи CUIT.
Просто нажимаем Record и запускаем приложением, которое необходимо протестировать.
Запись CUIT
Выполняем все действия, которые хотим протестировать (позже можно будет их отредактировать).
Можно также использовать кнопку Target для создания проверок состояния элементов пользовательского интерфейса.
Кнопка Generate Code преобразует выполненную последовательность действий в код модульного теста. Сгенерированный код можно менять по своему усмотрению. Например, удалить нечаянно выполненное действие.
Выполнение CUIT
CUIT выполняются аналогично остальным модульным тестам. При работе с репозитарием, UI тесты следует загружать вместе с остальными тестами, и они выполнятся как часть тестов проверки сборки.
Подсказка: Пока выполняются CUIT, не стоит прикасаться к мышке и клавиатуре.
Изменение и добавление проверок
Итак, у нас уже есть последовательность действий, преобразованная в исполняемый код. При выполнении этого кода, записанные действия воспроизводятся.
Но не хватает собственно проверок. Код, тестирующий состояния элементов UI, нужно добавлять самостоятельно. Используя кнопку Target можно создать прокси объект, который будет представлять выбранный элемент UI. После этого пишется код, использующий публичные методы таких прокси объектов для того, чтобы тестировать состояния элементов.
Расширение обычной процедуры для использования множества значений
Код можно изменять для того, чтобы записанная процедура повторялась с разными входящими значениями.
Самый простой вариант – это добавить в код цикл и наборы значений.
А можно связать тест с отдельной таблицей значений, которая может быть файлом электронных таблиц, файлом XML или базой данных. Например, в Excel рисуется таблица, в которой каждый ряд – это набор данных для каждого повторения цикла. В каждой колонке предоставляются значения для определенной переменной. Первый ряд – это шапка, в которой определены имена переменных:
Вкус Размер
Овсянка Маленькая
Селедка Большая
В свойствах теста создается новая связь (Data Connection String). Мастер создания связей позволяет выбрать источник данных. Внутри кода можно писать выражения типа
C#
var flavor = TestContext.DataRow[“Вкус”].ToString();
Изоляция
Как и при работе с любым модульным тестом, тестируемые компоненты или уровни можно изолировать – в данном случае пользовательский интерфейс – предоставляя фальшивый бизнес уровень. Подмена должна просто вести журнал вызовов и иметь возможность менять свои состояния так, чтобы с помощью проверок можно было убедиться, что пользовательский интерфейс совершил правильные вызовы и правильно отобразил состояние.
Хорошо изолированные модульные тесты
Как быть с подходом «сначала тесты»?
В такой ситуации может показаться, что нецелесообразно писать тесты до того, как написан код. Ведь нужно создать интерфейс пользователя перед тем, как записывать действия для CUIT.
В какой-то мере это справедливо, особенно если пользовательский интерфейс динамически реагирует на состояния бизнес логики. Тем не менее, часто можно записать некоторые действия над кнопками, которые особо ничего не делают во время записи, и добавить проверки, которые заработают после того, как будет подключена бизнес логика.
CUIT – это модульные или системные тесты?
Программируемые UI тесты являются очень эффективным способом быстро писать тесты. Если честно, то CUIT разрабатывались под две задачи: тестировать пользовательский интерфейс в изоляции (с подмененной бизнес логикой); и системное тестирование всего приложения (этой теме будут посвящены будущие заметки).
Но CUIT настолько быстрый способ создания тестов, что так и хочется расширить сферу их применения. Предположим, что создается маленькое десктопное приложение, которое пользуется базой данных или сетью. И бизнес логика определяется пользовательским интерфейсом. Очевидно, что быстрый способ написания тестов бизнес логики – это записать CUIT для всех основных функций, подменяя внешние источники (web или базу данных). Казалось бы, это более оптимальное использование времени, чем писать код для тестов бизнес логики.
Если прислушаться, то можно услышать громкое возмущение приверженцев современной методологии. Ведь тестирование бизнес логики нажатием кнопок в графическом интерфейсе намертво связывает UI и бизнес логику. А это ставит крест на лучших практиках разработки, которые требуют разделять интерфейс и логику. Причина банальна – при изменении пользовательского интерфейса перестают работать тесты бизнес логики.
Но это еще не все. Поскольку CUIT можно создать только после того, как программа уже запускается, следование такому подходу не позволит применить стратегию «сначала тесты» (которая позволяет сосредоточиться на идеях и обсуждении того, что именно должен делать код).
По этим причинам, мы не рекомендуем использовать CUIT как замену правильным модульным тестам бизнес логики. Лучше думать о бизнес логике как определяемой API (зависящей от других компонент кода), а об UI просто как об одном из способов вызывать действия API. Ну а для написания API, хорошо начинать с написания примеров последовательностей вызовов, которые станут частью тестовых методов.
Если есть уверенность в том, что приложение будет жить недолго, оно мало и незначительно, тогда CUIT могут быть отличным способом быстро набросать несколько тестов.
CUIT для тестирования приложения
Дизайн программируемых UI тестов
При запуске теста, движок CUIT должен найти каждый элемент управления, который используют записанные действия. Это достигается с помощью прохода по дереву представления, используя имена элементов UI. Если пользовательский интерфейс был изменен, тесты могут не работать из-за того, что не смогут найти элементы. Хотя у движка есть некоторая эвристика для поиска изменившихся элементов, можно увеличить ее шансы сработать:
- В HTML у каждого элемента должен быть идентификатор.
- В Windows технологии презентаций надо использовать Accessibility.
- При разработке своих элементов управления, можно определить расширение CUIT для того, чтобы помочь программе записи распознавать действия (подробнее в теме MSDN Enable Coded UI Testing of Your Custom Controls).Например, при использовании элемента выбора файла, записывается не последовательность кликов, а какой файл был выбран.
Поддержание работоспособности программируемых UI тестов
Недостатком CUITs является то, что они должны быть воспроизводимы даже при значительных изменениях пользовательского интерфейса. Можно минимизировать необходимые усилия по обеспечению работоспособности CUIT:
- Создавать отдельные записи, тем самым разделяя методы, для разных форм или страниц, а также для групп из небольшого количества действий.
- В случае изменений определять затронутые методы и перезаписывать только их тесты.
- Использовать редактор CUIT для обновления кода. Код можно изменять и напрямую, но при использовании редактора результаты получаются более надежными. Больше информации в теме MSDN How to: Edit a Coded UI Test Using the Coded UI Test Editor.
