Чуть больше года назад я впервые попробовал Robot Framework. За время участия в довольно масштабном проекте я испытал два разных подхода к автоматизации тестирования с помощью этого инструмента: написание тестов на чистом DSL Robot Framework и работа в связке с Python. Если у первого пути низкий порог входа, то второй, на мой взгляд, более удобен с точки зрения поддержки крупных проектов.
Хотя принципиальной разницы между подходами нет. Так или иначе, все сводится к поиску библиотек.
Однако стоит поговорить о специфике подходов.
Кто такой Робот и с чем его едят?
Возможно, нам следует начать с внедрения этого мощнейшего инструмента.Robot Framework — это платформа для тестирования на основе ключевых слов.
Он используется для автоматизации приемочного тестирования и ATDD (подход к разработке, основанный на приемочном тестировании).
Эта система имеет простой в использовании синтаксис тестовых данных и позволяет автоматизировать тесты с использованием ключевых слов.
Кроме того, Robot Framework имеет отличные встроенные и сторонние библиотеки, которые позволяют быстро приступить к работе и интегрировать автоматизацию в рабочие процессы, не изобретая собственные колеса — тот самый низкий входной барьер, о котором я упоминал выше.
Основная структура Robot Framework реализована с использованием Python, а также работает на Jython (JVM) и IronPython (.
NET).
Примеры использования, а также полную документацию по фреймворку и внутренним библиотекам можно найти на официальном сайте проекта: http://robotframework.org/ .
Мои первые шаги.
Подход один Впервые я столкнулся с Robot Framework год назад, после смены работы.
До этого я автоматизировал только на Java и C#.
Выбирая для себя инструменты, с помощью которых мне придется иметь дело с существующими тестами, я опросил новых коллег об их предпочтениях.
У них не было единого мнения относительно лучшей IDE для работы с Robot Framework. По сути, плагины для различных текстовых редакторов и IDE, например PyCharm, позволяют работать с Robot Framework. А рекомендации, которые я собрал, были разделены 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, а файлы робота просто копировались в целевой каталог для последующего выполнения.
Тесты запускались скриптами (файлы .
bat или .
sh), которые брали путь либо к отдельному тест-кейсу (отдельный файл .
robot), либо к плану тестирования (файл со списком относительных путей к тест-кейсам).
Рефакторинг затронул большое количество тестов, поэтому первый запуск занял около 15 минут. После завершения пришло время просмотреть отчеты, предоставляемые Robot Framework. Стандартный отчет (на скриншоте выше) состоит из файлов report.html и log.html:
- отчет содержит общую сводку о прошлом прогоне, где можно увидеть поверхностные результаты всех тестов (пройдено или не пройдено);
- в лог-файле можно увидеть более подробную информацию — пошаговое выполнение каждого теста.
Там же можно отобразить все необходимое для отладки тестов.
чтения такого журнала.
Но это дело не такое уж и сложное.
Через пару месяцев я мог процитировать «Матрицу»: «Ваш мозг сам делает перевод. Я даже больше не вижу кода.
Я вижу блондинку, брюнетку и рыжую».
Я так и сделал - всю необходимую информацию увидел в файле без дополнительных инструментов.
Преимущество состоит в том, что вывод можно контролировать: существуют разные уровни журналирования, которые определяют, какая информация будет выводиться, а какая нет. Уровень можно настроить для каждой линии отдельно, используя встроенный в библиотеку метод. В этом случае полезно знать порядок выполнения вызовов внутри тестовых и вспомогательных библиотек — так легче уловить момент ошибки.
Используя 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. Потихоньку начали писаться первые тесты и вспомогательные библиотеки для нашей подсистемы.
За то время, пока у меня была возможность работать с новым подходом, я почувствовал, что с другим инструментом действительно больше возможностей.
Но по сути написание тестов мало что изменилось.
В этом конкретном проекте методы встроенных библиотек Robot Framework по-прежнему вызывались внутри кода Python. Это было связано со специфическими требованиями заказчика к разработке тестов.
Мы просто отделили исполняемую часть от алгоритма тестового примера.
Что лучше?
Лично мне нравится второй подход. Однако при выборе пути своего проекта следует исходить из задачи — кто и как пишет тесты.Как я уже говорил выше, Python (второй подход) предоставляет больше возможностей, но в данном случае проекту нужны люди, знакомые с этим языком.
Сама платформа Robot Framework (и первый подход) менее требовательна — вы можете подойти к ней, прочитав официальную документацию по ее DSL. Изучив руководство пользователя, вы сможете создавать любые тесты — они будут выглядеть вполне чисто.
В результате Robot Framework и то, как мы его использовали вначале, больше подходят вчерашним ручным тестировщикам без явного опыта программирования на языках высокого уровня.
Написать тест сможет даже человек, не сильно разбирающийся в программировании, просто назвав нужные ключевые слова.
Однако если по примеру нашего проекта вы хотите сохранить исполняемую часть отдельно, и при этом провести рефакторинг кода в дружественных IDE, второй подход для вас.
Автор статьи: Дмитрий Мастеров P.S.: Наши статьи мы публикуем на нескольких сайтах Рунета.
Подпишитесь на наши страницы по адресу ВК , ФБ или Telegram-канал чтобы узнать обо всех наших публикациях и других новостях Maxilect. Теги: #robot framework #jython #python #java #atom #vscode #тестирование #тестирование программного обеспечения #тестирование приложений #тестирование ИТ-систем #python #java #Управление продуктом
-
Релокация В Финляндию Для Разработчиков
19 Oct, 24 -
Доброе Утро
19 Oct, 24 -
Документы Google Офлайн
19 Oct, 24 -
Bittorrent Трекер На C#
19 Oct, 24
