Комментарии 11
Зато у RIDE есть одна фича, которой нет у других — можно просто мышкой поставить галочки в тестах, которые хочется прогнать, а не писать их аргументами.
Ещё есть RED на основе Eclipse. https://github.com/nokia/RED
Для запуска нужных тестов проще воспользоваться тегами чем писать их в аргументах.
Не хочется защищать робот, но оставлю это здесь:
устаревшая и неинформативная документация
Вот тут не согласен. В роботе все норм с документацией. К ней просто надо адаптироваться немного )) И не сказать что робот это прям легаси. Непотребство конечно местами, но точно не легаси.
Тем более смешивать и делать помесь Java с Python
Это больно да.
Я например чисто никому не рекомендую с ним даже связываться
У робота есть один фатальный недостаток — несмотря ни на что он работает.
В больших компаниях должны немного задумываться о том какую роль выполняют автоматизаторы, и как должен поддерживаться и обновляться код
Создатели робота проповедуют, что робот может быть использован тестировщиками которые не хотят и не могут програмировать. И я всегда немного фейспалмлю на этой ноте. Как-то за этой фразой как бы умалчивается, что у робота очень странный синтаксис с которым все равно надо разбираться и что написание автотестов в какой-то мере все равно самое настоящее програмирование.
я испытал на своей шкуре два разных подхода к автоматизации тестирования с помощью этого инструмента: написание тестов на чистом 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 и то, как мы его использовали поначалу, больше подойдут вчерашним ручным тестировщикам без явного опыта программирования на языках высокого уровня.
Но только надо пояснить, что программировать так или иначе все равно придётся.
Это по сути подход в котором идет отказ от робота. И тогда не понятно к чему эта статья была
Статья просто об опыте столкновения с роботом, а не о рекомендации к использованию)
Я не особо понял из поста в чем смысл второго подхода. То есть сами тесты пишутся на питоне и вызываются как киворды? Какой-то кейс не очень, не проще ли сразу что-то человеческое использовать для разработки тестов на самом питоне?
Это подобно связке Java + Cucumber получается. Больше фишка для «манагеров»
Вот это очень больно и даже через чур. Не уж то в роботе есть что-то такое чего нет в самом питоне?
Неа. Полагаю, что так «исторически» сложилось
Статья просто об опыте столкновения с роботом, а не о рекомендации к использованию)
Выводов не хватает из которых можно было бы чётко понять к чему пост вёл.
Неа. Полагаю, что так «исторически» сложилось
Искоренять такое легаси бесщадно и не приветствовать на код ревью.
Мой опыт знакомства и работы с Robot Framework