Чуть более года назад я впервые попробовал в работе Robot Framework. За время моего участия в довольно масштабном проекте я испытал на своей шкуре два разных подхода к автоматизации тестирования с помощью этого инструмента: написание тестов на чистом DSL Robot Framework и работу в связке с Python. Если первый путь имеет низкий порог входа, то второй, на мой взгляд, удобнее с точки зрения поддержки крупных проектов. Хотя фундаментальной разницы между подходами нет. Так или иначе, все сводится к поиску библиотек.

Однако об особенностях подходов поговорить стоит.

Кто такой Robot и с чем его едят

Наверное, стоит начать с представления этого мощнейшего инструмента.

Robot Framework – это фреймворк для keyword-driven-тестирования. Он используется для автоматизации приемочного тестирования и ATDD (подхода к разработке через приемочное тестирование). Эта система имеет простой в использовании синтаксис тестовых данных и позволяет автоматизировать тесты с использованием ключевых слов. Кроме того, у Robot Framework есть отличные встроенные и сторонние библиотеки, позволяющие без изобретения собственных велосипедов быстро начинать и встраивать автоматизацию в рабочие процессы – тот самый низкий порог входа, о котором я говорил выше.

Основная структура Robot Framework реализована с использованием Python и работает также на Jython (JVM) и IronPython (.NET).

Примеры использования, а также полную документацию по фреймворку и внутренним библиотекам можно найти на официальном сайте проекта: http://robotframework.org/.

Мои первые шаги. Подход первый

Впервые с Robot Framework я столкнулся год назад, после смены места работы. До этого мне доводилось автоматизировать только на Java и C#.

Выбирая для себя инструментарий, с которым придется разбираться в существующих тестах, я опросил новых коллег на тему их предпочтений. Единого мнения о лучшей IDE для работы с Robot Framework у них не было. В основном работать с Robot Framework позволяют плагины для различных текстовых редакторов и IDE, типа PyCharm. И собранные мной рекомендации разделились 50/50 между Atom и PyCharm. Конечно, есть RIDE, но это не панацея. На тот момент (год назад) я не нашел по ней нормальной документации, а в той, что нашел, не увидел каких-то больших плюсов для своей задачи. Поэтому для начала решил попробовать Atom с плагинами. Клонировав репозиторий, стал потихоньку изучать, что же происходит в наших тестах и в самом Robot Framework.

Меня подключили к проекту фактически на все готовенькое. Там уже работала связка Jython + Robot Framework, была собрана огромная кодовая база (написанная на самом DSL Robot Framework) из более чем 1000 тестов и нескольких тысяч строк кода вспомогательных библиотек на Java.

Как я понимаю, когда проект начинался, т.е. еще до моего прихода в отдел, над ним в основном работали специалисты по Java, да и сам тестируемый продукт был на Java, поэтому, выбирая подход, ориентировались на имеющиеся ресурсы. В целом расчет был примерно такой: решив некоторые проблемы, связанные с интеграцией Robot Framework и Java (в основном из-за того, что Java – компилируемый язык, а тот же Python и тесты в связке Python + RF – интерпретируемые), можно было потом легко привлекать сторонних специалистов, знающих только DSL Robot Framework, и спокойно писать тесты на кейвордах. Правда, коллегам пришлось затратить довольно много усилий в создание библиотек на Java, поэтому без условий со стороны заказчика они такой путь рекомендовать бы не стали.

Проделав небольшой рефакторинг, в рамках своей первой задачи я впервые запустил тесты. Поскольку использовалась связка Jython + RF, все собиралось maven, а robot-файлы просто копировались в target-директорию для последующего исполнения.

Запускались тесты скриптами (файлами .bat или .sh), которые принимали путь либо к отдельному тест кейсу (отдельному файлу .robot), либо к тест-плану (файлу со списком относительных путей до тест-кейсов).

Рефакторинг затронул большое количество тестов, поэтому первый прогон занял минут 15. После его окончания пришло время взглянуть на отчеты, предоставляемые Robot Framework.
Стандартный отчет (на скриншоте выше) состоит из файлов report.html и log.html:

• report содержит в себе общую сводку о прошедшем прогоне, где можно увидеть поверхностные результаты всех тестов (Passed или Failed);
• в log-файле можно увидеть более детальную информацию – выполнение каждого теста пошагово. Там же можно выводить все, что нужно для отладки тестов.

Честно говоря, от первого взгляда на отчет Robot Framework начинает немного дергаться глаз: выводится огромное количество информации и требуется какое-то время, чтобы понять сквозную структуру тестов и выработать навык чтения подобного лога. Но это дело не столь уж хитрое. Уже через пару месяцев я мог цитировать «Матрицу»: «Твой мозг сам делает перевод. Я уже даже не вижу код. Я вижу блондинку, брюнетку и рыжую». Так и я – видел всю необходимую информацию в файле без дополнительных инструментов.

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

Используя в качестве основного средства DSL Robot Framework, мы проработали около полугода. За это время я из личных предпочтений перешел с Atom на VSCode, но сути подхода это не меняло.

Однако проект развивался. В финальной итерации вспомогательная библиотека для работы с БД насчитывала 6700 строк кода на чистом Robot Framework. При таких масштабах кодобазы ее стало сложно поддерживать – на рефакторинг требовались ресурсы, которые не были выделены.
Финальное слово в применении первого подхода принадлежало бизнесу. Заказчик нашего проекта вел работу и с другими командами над смежными задачами. В одном из параллельных треков он увидел, с его точки зрения, более результативный и наглядный именно для менеджмента вариант использования Robot Framework, который и начали внедрять.

Подход второй

Второй подход представлял собой разработку тестов на Python в связке с Robot Framework. Вместо того, чтобы создавать все на синтаксисе DSL Robot Framework, мы начали писать вспомогательные библиотеки и прочие низкоуровневые взаимодействия с тестируемым продуктом на Python. А Robot Framework, по сути, становился просто раннером.

Поскольку Python – чистый высокоуровневый язык, а не DSL, тут больше возможностей по структурированию, легче во всем этом разобраться. Как минимум, можно использовать IDE для Python, которая поможет найти одинаковые методы (они делают одно и то же, но называются по-разному) или даже часть кода за тебя напишет. Какие-то данные можно было оборачивать в генераторы, на функции навешивать декораторы и т.п. На этом фоне инструментарий первого подхода (чистого Robot Framework) выглядит довольно сурово – по сути, то был «Блокнот» с подсветкой синтаксиса. Никаких тебе сеттеров или геттеров, которые IntelliJ пишет за тебя. Так что я был рад вернуться к высокоуровневому языку. Работа с данным подходом больше похожа на обычную разработку. Правда, есть и ложка дегтя. Без дополнительных плясок понять, что упало внутри Python, вызванного из RF, невозможно.

Потихоньку начали писаться первые тесты и вспомогательные библиотеки для нашей подсистемы. За то время, что мне довелось работать с новым подходом, я ощутил, что с другим инструментом действительно появляется больше возможностей. Но по сути написание тестов не сильно видоизменилось. В данном конкретном проекте внутри Python-кода все равно вызывались методы встроенных библиотек Robot Framework. Это было связано с особенностью требований заказчика к разработке тестов. Мы просто отделили исполняемую часть от алгоритма тест-кейса.

А что лучше?

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

Как я уже говорил выше, Python (второй подход) дает больше возможностей, однако в этом случае на проекте необходимы люди, знакомые с этим языком. Сам по себе Robot Framework (и первый подход) менее требователен – к нему можно подступиться, прочитав официальную документацию по его DSL. Уже после изучения user guide можно создавать любые тесты – они будут выглядеть довольно чисто.

В итоге Robot Framework и то, как мы его использовали поначалу, больше подойдут вчерашним ручным тестировщикам без явного опыта программирования на языках высокого уровня. Написать тест сможет даже человек, не сильно причастный к программированию, просто вызывая необходимые ключевые слова.

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

Автор статьи: Дмитрий Мастеров

P.S.: Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.