Мой опыт знакомства и работы с Robot Framework

Кто такой 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.