Comments
А как выполнена интеграция с Jira?
Идентификатор Issue становится тэгом?
Да, для интеграции тег соответствует Jira Issue ID. Кроме того, Robot Framework надо запускать в ключиком, чтобы из лога можно было напрямую перейти в Jira.
Допустим у Вашего проекта в Jira префикс RF, то есть баг у Вас с идентификатором RF-123456. Тогда Вы привязываете к тесту тэг RF-123456, а в строке запуска робота пишете

tagstatlink RF-*:https://ваш-хост-с-jira/browse/RF-%1:Open_in_Jira

и все тэги, начинающиеся с RF- получат ссылки в Jira (из моего любимого лога).

А какие инструменты вы используете при работе?
Мы попробовали робот чуть меньше года назад и ушли на pytest с чистой совестью. Интеграция с PyCharm через энное место и стабильно крашится, дебажить неудобно.

При написании тестов удобно пользоваться и PyCharm, и Atom с соответствующими плагинами. Некоторые не гнушаются даже стандартным Блокнотом. Дебаг в общепринятом смысле тут недоступен — да. Но как мы уже писали в статье, у робота прекрасный лог и его вполне достаточно для тех нужд, для которых обычно используется дебаг.

Наша команда сравнивала pytest и робот параллельно, дабы постепенно перейти с цирка на баш+c#+python+java. И вот как раз по поводу лога, всех сильно удивило, что робот не умеет показывать строку, где тест упал. Ну то есть можно подключить стектрейс руками, но очень странно, что это issue на гитхабе до сих пор висит открытым.


Для расчета покрытия я написал утилиту, которая берет из Swagger список API бэкенда и сопоставляет его с тем, что было протестировано.

Интересно было бы почитать про это. Просто сравнение по вызываемым эндпойнтам или какие-то тонкости?

Если вкратце, то в автотестах есть метод, который логирует каждый вызов API — URL, параметры и теги, с которыми был запущен тест, совершивший этот вызов. После выполнения тестов вручную (или силами CI) запускается утилита для анализа лога.
Утилите указываются все теги, для которых рассчитывается покрытие (например, smoke), а она выбирает из файла записи, соответствующие указанным тэгам.
Затем она идёт по нужному адресу в Swagger и вытягивает оттуда информацию об «энд-поинтах», методах, и параметрах — ну и сопоставляет эти данные, выводя статистику относительно всех эндпоинтов и методов.
В файле лога большинство вызовов содержат какие-то идентификаторы и на самом деле их сложно сопоставить с тем, что лежит в Swagger. Поэтому в утилиту заложена хитрая логика, которая умеет выделять идентификаторы из URL и делать на их основе пометки, впоследствии используемые при сопоставлении.
Помимо развёрнутой информации (что покрыто, что не покрыто, что покрыто частично — когда использованы не все параметры) она генерит ещё и svg-плашку, которая выводится в описании проекта gitlab.

Мы наоборот отказались от RF и перешли на стек Java + Junit 5 + Selenide + Allure, плюс пару обёрток для базы и ssh. Когда я пришёл на проект тесты выглядели как кровавое месиво из частей на чистом RF, чистом python и какой-то адовой мешанине их же. Возможности запустить тесты в параллели нет, прогон идёт 4 часа.
В RF нет нормального дебага, работа с кодом в pycharm это ад, при чтении этого прекрасного отчёта длиною в жизнь просто кровь из глаз.
Бэкенд у нас на Java и когда разработчик которому приходилось поддерживать эти чудные тесты увидел что можно просто поставить в intelliJ idea брекпойнт и код можно дебажить — чуть не прослезился. Отчёты Аллюра с их Step аннотациями очень понравились всем.

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