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

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

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


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

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


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

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


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

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


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

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

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

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

я испытал на своей шкуре два разных подхода к автоматизации тестирования с помощью этого инструмента: написание тестов на чистом 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 получается. Больше фишка для «манагеров»

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


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

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


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

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

Only those users with full accounts are able to leave comments. Log in, please.