Тренажер Torneo Jazz. У него подставочка под телефон есть, но ноут туда тоже отлично ложится. Только вот чтобы он на кнопки не нажимал, приходится подкладывать что-то между панелью и ноутом. У меня там сейчас упаковка антибактериальных салфеток)
Стол ИКЕА Бекант трансформер. Выбирал между ним и “Скарста”, но спустя время пожалел, что взял с электроприводом. Поднимаю его не чаще раза в день, мог бы и рукой покрутить, время не сильно больше уходит.
Стул из того же магазина. Называется Маркус. До этого сидел на Самурае. В холодное время года не жалел о новом выборе, но вот сейчас начинаю задумываться, становится жарковато.
Он стандартный за исключением пары небольших особенностей. React для управления состоянием свое redux-like решение с возможностью точечных подписок на необходимые редьюсеры. Redux-act для борьбы с бойлерплейтом. Тесты на testing-library/react и cypress, еще очень сильно любим ramda и reselect.
Все зависит от базы и направления. Во фронте люди растут быстрее. На бэкенде со сложной архитектурой и высокими нагрузками 5 лет действительно может быть недостаточно.
Если вкратце, то в автотестах есть метод, который логирует каждый вызов API — URL, параметры и теги, с которыми был запущен тест, совершивший этот вызов. После выполнения тестов вручную (или силами CI) запускается утилита для анализа лога.
Утилите указываются все теги, для которых рассчитывается покрытие (например, smoke), а она выбирает из файла записи, соответствующие указанным тэгам.
Затем она идёт по нужному адресу в Swagger и вытягивает оттуда информацию об «энд-поинтах», методах, и параметрах — ну и сопоставляет эти данные, выводя статистику относительно всех эндпоинтов и методов.
В файле лога большинство вызовов содержат какие-то идентификаторы и на самом деле их сложно сопоставить с тем, что лежит в Swagger. Поэтому в утилиту заложена хитрая логика, которая умеет выделять идентификаторы из URL и делать на их основе пометки, впоследствии используемые при сопоставлении.
Помимо развёрнутой информации (что покрыто, что не покрыто, что покрыто частично — когда использованы не все параметры) она генерит ещё и svg-плашку, которая выводится в описании проекта gitlab.
При написании тестов удобно пользоваться и PyCharm, и Atom с соответствующими плагинами. Некоторые не гнушаются даже стандартным Блокнотом. Дебаг в общепринятом смысле тут недоступен — да. Но как мы уже писали в статье, у робота прекрасный лог и его вполне достаточно для тех нужд, для которых обычно используется дебаг.
Да, для интеграции тег соответствует Jira Issue ID. Кроме того, Robot Framework надо запускать в ключиком, чтобы из лога можно было напрямую перейти в Jira.
Допустим у Вашего проекта в Jira префикс RF, то есть баг у Вас с идентификатором RF-123456. Тогда Вы привязываете к тесту тэг RF-123456, а в строке запуска робота пишете
Мне знакома позиция: «Никто никому ничего не должен. Работает — не трогай!»
Но как тогда делать рабочий процесс лучше? Откуда менеджмент узнает о проблемах Ларри, если Ларри не укажет на них и не подскажет возможный вариант решения?
Мне бы на месте Ларри было стыдно, что я не сделал все, что мог — ни для себя, ни для коллег, которые так же мучаются в тех же самых рутинных процессах…
Стул из того же магазина. Называется Маркус. До этого сидел на Самурае. В холодное время года не жалел о новом выборе, но вот сейчас начинаю задумываться, становится жарковато.
Утилите указываются все теги, для которых рассчитывается покрытие (например, smoke), а она выбирает из файла записи, соответствующие указанным тэгам.
Затем она идёт по нужному адресу в Swagger и вытягивает оттуда информацию об «энд-поинтах», методах, и параметрах — ну и сопоставляет эти данные, выводя статистику относительно всех эндпоинтов и методов.
В файле лога большинство вызовов содержат какие-то идентификаторы и на самом деле их сложно сопоставить с тем, что лежит в Swagger. Поэтому в утилиту заложена хитрая логика, которая умеет выделять идентификаторы из URL и делать на их основе пометки, впоследствии используемые при сопоставлении.
Помимо развёрнутой информации (что покрыто, что не покрыто, что покрыто частично — когда использованы не все параметры) она генерит ещё и svg-плашку, которая выводится в описании проекта gitlab.
Допустим у Вашего проекта в Jira префикс RF, то есть баг у Вас с идентификатором RF-123456. Тогда Вы привязываете к тесту тэг RF-123456, а в строке запуска робота пишете
tagstatlink RF-*:https://ваш-хост-с-jira/browse/RF-%1:Open_in_Jira
и все тэги, начинающиеся с RF- получат ссылки в Jira (из моего любимого лога).
Но как тогда делать рабочий процесс лучше? Откуда менеджмент узнает о проблемах Ларри, если Ларри не укажет на них и не подскажет возможный вариант решения?
Мне бы на месте Ларри было стыдно, что я не сделал все, что мог — ни для себя, ни для коллег, которые так же мучаются в тех же самых рутинных процессах…