Карта города и справочник предприятий
216,62
рейтинг
22 апреля 2014 в 11:46

Дизайн → Автоматизация тестирования UI. От Coded UI к Cruciatus

Как вы знаете, 2ГИС помогает найти самую разную актуальную информацию об организациях города. Она собирается из различных источников при помощи специализированных продуктов, с которыми работают картографы 2ГИС, специалисты call-центра и отдела продаж. Эти продукты мы называем внутренними, и кроме сбора информации они также умеют её обрабатывать, фильтровать, объединять и выгружать в нужных форматах конечным приложениям 2ГИС.

Внутренние продукты разрабатывают отдельные проектные команды, в основном, на стеке технологий Microsoft. Для отрисовки графического интерфейса используется WPF или наследственный WinForms. Одни приложения построены на элементах управления из «коробки», другие используют, например, библиотеку AvalonDock. Так же встречаются приложения, разработанные на платформе Catel.

Такое разнообразие порождает проблемы автоматизации тестирования. Мы их успешно решили в рамках проекта Cruciatus — собственного фреймворка, который позволяет упростить разработку тестов для проверки пользовательского интерфейса.

Несмотря на название, Cruciatus вполне легален и за его использование вас не упекут в Азкабан. В этой статье мы расскажем о Сruciatus подробнее.


Выбираем волшебную палочку инструмент




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

Для desktop-приложений под Windows мы рассмотрели несколько самых популярных инструментов: Visual Studio CodedUI, Ranorex, White и выбрали наиболее подходящее для тестирования наших внутренних продуктов. Ранее на Хабре мы писали, какими принципами руководствовались при выборе.

Напомним, что мы сделали свой выбор в пользу CodedUI. Он не выигрывал по всем пунктам, но имел весомое преимущество в том, что работа с ним происходит непосредственно в Visual Studio, которая является основной средой разработки для разработчиков и тестировщиков.

Зачем нам бумеранг, если у нас есть грабли


Рекордер является отличительной особенностью CodedUI, так как позволяет создавать тесты даже без навыков программирования.

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

Так как к тому времени мы уже имели представление о работе CodedUI, мы отложили рекордер в сторону и стали писать код тестов самостоятельно, используя классы, предоставляемые пространством имён Microsoft.VisualStudio.TestTools.UITesting (их использует и сам CodedUI при генерации кода). Это позволило нам получать тесты с понятным, компактным кодом, но не избавило от проблем поиска элементов и их доступности. Что заблокировало дальнейшее продвижение автоматизации тестирования пользовательского интерфейса.

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



Нас полностью устраивала работа компоненты, эмулирующей действия мыши и клавиатуры: классы Mouse & Keyboard прекрасно с этим справляются. В отличии от классов, которые отвечают за доступ к приложению и являются крайними за упомянутую проблему поиска и доступности элементов. В связи с этим хочется их вырезать и заменить!

Своя обертка ближе к телу


Для того, чтобы элемент приложения мог о себе что-то сказать, он должен реализовывать технологию Microsoft UI Automation. В таком случае он позволяет программно обращаться к нему, используя библиотеки из пространства имен System.Windows.Automation. Они применяются, например, в уже упомянутом на диаграмме классе WpfTestProvider. Мы попробовали напрямую использовать библиотеку Automation и получили отличный результат, избавившись от проблем поиска элемента и их доступности.

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

Так, следующим этапом развития нашего проекта стала разработка обёртки над UI Automation, которая заменит неудовлетворяющие нас классы,



аккумулирует удовлетворяющие,



а для тестировщика будет универсальным и удобным в использовании инструментом.

Магическое преображение


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

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



Используя карту, пишем тесты. Ниже пример теста, проверяющего, что при установленной галочке (у элемента SwitchCheckBox) элемент ComboBox включен, и наоборот:

[CodedUITest]
public class Class1
{
    [TestMethod]
    public void CheckingSwitchCheckBox()
    {
        var app = new Application<MainWindow>("Application.exe", "WindowUid");
        app.Start();
        app.MainWindow.TabItem2.SwitchCheckBox.Uncheck(); // отключает ComboBox
        Assert.IsFalse(app.MainWindow.TabItem2.ComboBox.IsEnabled);
        app.MainWindow.TabItem2.SwitchCheckBox.Check(); // включает ComboBox
        Assert.IsTrue(app.MainWindow.TabItem2.ComboBox.IsEnabled);
        app.Close();
    }
}


Автоматизируй и реквестируй


Фреймворк доступен на GitHub, документация прилагается. Продукт полностью готов к использованию. Изначально Cruciatus разрабатывался для личного использования, но сейчас он вырос в самостоятельный продукт, который мы активно развиваем.

Скачивайте, форкайте, реквестируйте фичи. Мы рады вашим пожеланиям и предложениям.
Автор: @skyline-gleb
2ГИС
рейтинг 216,62
Карта города и справочник предприятий

Комментарии (9)

  • 0
    Полезная статья!
    Интересно было бы почитать еще, какие средства для автоматизации тестирования Вы используете на Андроид. Я так пока и не нашел ни одного инструмента, где можно было бы записывать действия, а не писать все вручную кодом.
    • 0
      Спасибо!
      По Андроиду, а так же другим мобильным платформам, могу сказать, что развитие автоматизации тестирования в процессе и как только получим хороший результат, обязательно им поделимся.
      • 0
        Буду ждать! Пожалуйста, обязательно напишите о своем опыте.

        А по теме автотестов на Винде. Я в свое время тоже исследовал средства Visual Studio 2010. Тест сперва записывался с пользователя (себя то есть), потом корректировался в коде. Памяти при этом ел как не в себе, зато переваривал и веб-проекты (Sharepoint-портал), и десктопное приложение.
  • 0
    Извиняюсь, если не нашёл, но почему вы отвергли Test Stack White?
    • +1
      В статье действительно про TestStack.White только упоминается, без подробностей))
      Вообще инструмент хороший и довольно большой, но попробовав его использовать столкнулись с ошибками при работе с элементами… подробности уже помнятся смутно, но суть ошибок заключалась в конфликте между «не стандартными» элементами и подходом к взаимодействию с ними в TestStack.White. В действительности данный фреймворк был рассмотрен уже после сравнения Ranorex и CodedUI и с учетом этих знаний было решено сделать свой прототип, который себя оправдал.
      • 0
        Вариант допила White не рассматривали? М.б. это проще запиливания собственного фрэймворка?
        • 0
          Ошибки, с которыми мы столкнулись, не связанны с тем, что в TestStack.White есть проблемы, которые надо исправить и что-то допилить. Фреймворк просто не подошел нам.
  • +1
    Кстати, ведь с Андроид 4.1 (или 4.2) появился родной Гугловский инструмент для автоматизации тестов — UIAutomator
    developer.android.com/intl/ru/tools/testing/testing_ui.html
    Пока не нашел приложений, которые он был бы не в состоянии «переварить».
    Интересно было (мне) бы вкратце сравнить инструменты из статьи и от Гугла. На мой взгляд «родные» средства оказываются зачастую удобнее и стабильнее, чем сторонние.

    PS Хотя стоит отметить, что по «понятности» документация Гугла далека от идеала. «ТеперьЮ детально описав механизм, пишем тест. Он пишется так и так, используя скромненький Мега-модуль». Хммм, что такое «Мега-модуль»? А как его подключать? Лезешь смотреть, а там в доке простыня на десятки экранов. Но потом встречаешь статью на Хабре, где все расписано в паре экранов. И это работает!
  • НЛО прилетело и опубликовало эту надпись здесь

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

Самое читаемое Дизайн