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

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

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

    image

    Кто такой 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.
    Maxilect
    46,00
    Умные решения для вашего бизнеса
    Поделиться публикацией

    Комментарии 11

      0
      RIDE дико устарел, требует wxPython версии 2.8.12.1 (именно ее, хотя актуальная сейчас 4) и как следствие питон версии 2.х. Есть пара форков для третьей версии, но они до ума не доведены.

      Зато у RIDE есть одна фича, которой нет у других — можно просто мышкой поставить галочки в тестах, которые хочется прогнать, а не писать их аргументами.
        0

        Ещё есть RED на основе Eclipse. https://github.com/nokia/RED


        Для запуска нужных тестов проще воспользоваться тегами чем писать их в аргументах.

          0
          Далеко не всегда.
          +1
          Я всегда стараюсь уйти от разговора, когда разговор заходит о RobotFramework. Было несколько тетсовых заданий на нем при поиске работы автоматизатором, в свое время… При самом первом знакомстве я испытал всю боль автоматизаторов на данном проекте, устаревшая и неинформативная документация, примеров очень и очень мало, комьюнити почти никакое, — супер легаси код и кейворды, которые были в свое время написаны дядьками, до того как вообще родился… Я допустим не считаю нужным даже на нем заострять внимание при подборе фремворков для автоматизации на Python… Тем более смешивать и делать помесь Java с Python… В моем коментарии есть только боль… Я например чисто никому не рекомендую с ним даже связываться… В больших компаниях должны немного задумываться о том какую роль выполняют автоматизаторы, и как должен поддерживаться и обновляться код. Потому что сидеть 2 года как по мне на каком-толегаси проекте и не плучать нормального ценного опыта в актуальных технологиях — это бессмысленно и мне кажется что заработная плата таких сотрудников должна быть на много больше остальных, потому что человек поддерживая все это, жертвует: времеенем, опытом, нервами и здоровьем…
            0

            Не хочется защищать робот, но оставлю это здесь:


            устаревшая и неинформативная документация

            Вот тут не согласен. В роботе все норм с документацией. К ней просто надо адаптироваться немного )) И не сказать что робот это прям легаси. Непотребство конечно местами, но точно не легаси.


            Тем более смешивать и делать помесь Java с Python

            Это больно да.


            Я например чисто никому не рекомендую с ним даже связываться

            У робота есть один фатальный недостаток — несмотря ни на что он работает.


            В больших компаниях должны немного задумываться о том какую роль выполняют автоматизаторы, и как должен поддерживаться и обновляться код

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

              +1
              Я тоже не понимаю зачем писать DSL, который придется потом поддерживать, расширять и еще потом все это в таблицах каких-то хранить — это прям как писать тесткейсы в экселе. Это как если умеешь водить автомобиль — возить свою тачку на трамвае. Дико, страшно, больно — я отказываюсь верить в то, что это может быть правильным подходом.
                0
                Это как если умеешь водить автомобиль — возить свою тачку на трамвае.

                Вот это прекрасно было

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

              На самом деле все равно на нормальных проектах всё скатывается к использованию робота в связке с питоном (что очевидно так как робот по сути своей пакет для питона) и к написанию библиотек для него.


              Так или иначе, все сводится к поиску библиотек.

              Я бы уточнил, что так или иначе, все сведется к написанию библиотек. Так как фреимворк далеко не самый популярный, а те библиотеки, что можно под него найти зачастую страдают низким качеством кода.


              Честно говоря, от первого взгляда на отчет Robot Framework начинает немного дергаться глаз

              Вот что мне нравится в роботе так это его лог и дебаглог. Особо если робот отработал с --loglevel DEBUG.


              В финальной итерации вспомогательная библиотека для работы с БД насчитывала 6700 строк кода на чистом Robot Framework.

              6700 строк это прям ух.
              Если честно, то я тоже периодически сталкиваюсь с такими произведениями и это больно. Мой опыт подсказывает, что синтаксис робота хромает на две ноги и там где можно что-то написать на питоне, надо писать это на питоне и стремиться не городить библиотеки на роботе. А файлы ресурсов использовать только для какой-то специфики.
              Про синтаксис отдельно — я очень часто задумываюсь над тем, чем мог руководствоваться разработчик робота когда писал такое и почему в разных углах робота все сделано настолько по разному. Особый привет местным циклам :FOR. Хотя проблемы в роботе не только с синтаксисом, но есть и ряд концептуальных. Я очень негодую, почему премодифаеры и листенеры не наследуются от одного и того же и выглядят по разному, почему для сьюта тирдаун считается родительским элементом, а для кейса — нет, почему нельзя вложенный цикл сделать… И особая боль когда имена переменных городят из других переменных, типа такого: ${server_${prod}_port}.


              Второй подход представлял собой разработку тестов на Python в связке с Robot Framework.

              Я не особо понял из поста в чем смысл второго подхода. То есть сами тесты пишутся на питоне и вызываются как киворды? Какой-то кейс не очень, не проще ли сразу что-то человеческое использовать для разработки тестов на самом питоне?


              Без дополнительных плясок понять, что упало внутри Python, вызванного из RF, невозможно.

              Никаких плясок не надо. Если все нормально написано, то понять будет даже проще чем из самого робота.


              В данном конкретном проекте внутри Python-кода все равно вызывались методы встроенных библиотек Robot Framework.

              Вот это очень больно и даже через чур. Не уж то в роботе есть что-то такое чего нет в самом питоне?


              Лично мне по душе второй подход.

              Это по сути подход в котором идет отказ от робота. И тогда не понятно к чему эта статья была.


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

              Но только надо пояснить, что программировать так или иначе все равно придётся.

                0
                Это по сути подход в котором идет отказ от робота. И тогда не понятно к чему эта статья была


                Статья просто об опыте столкновения с роботом, а не о рекомендации к использованию)

                Я не особо понял из поста в чем смысл второго подхода. То есть сами тесты пишутся на питоне и вызываются как киворды? Какой-то кейс не очень, не проще ли сразу что-то человеческое использовать для разработки тестов на самом питоне?


                Это подобно связке Java + Cucumber получается. Больше фишка для «манагеров»

                Вот это очень больно и даже через чур. Не уж то в роботе есть что-то такое чего нет в самом питоне?


                Неа. Полагаю, что так «исторически» сложилось
                0
                Статья просто об опыте столкновения с роботом, а не о рекомендации к использованию)

                Выводов не хватает из которых можно было бы чётко понять к чему пост вёл.


                Неа. Полагаю, что так «исторически» сложилось

                Искоренять такое легаси бесщадно и не приветствовать на код ревью.

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

                Самое читаемое