Подскажите пожалуйста, какие отчеты используете на Jenkins? :-)

инфраструктура jenkins
, ,
#3

Спасибо за совет, но в обычные отчеты все равно придется шаги добавлять и придется в тесты писать еще один метод, с входящим параметром String, а в Allure подобное решается аннотация и достаточно листеннер логгера подключать и добавить к нему аннотации, выглядит это так:

@Override
@Step("Navigate to {0}")
public void afterNavigateTo(String url, WebDriver driver) {
    logger.info("navigated to " + url);
}

или что-то подобное в базовом пейдже или хелпере:

    public T open(String url) {
        if (url.startsWith("http:") || url.startsWith("https:")) {
            navigateToAbsoluteUrl(url);
        } else {
            navigateToAbsoluteUrl(absoluteUrl(url));
        }
        return (T) this;
    }

    protected String absoluteUrl(String relativeUrl) {
        String urlAbsolute = config.baseUrl + relativeUrl;
        return urlAbsolute;
    }

    @Step("Navigate to {0}")
    protected void navigateToAbsoluteUrl(String url) {
        driver.get(url);
    }

Но и вправду, зачем все усложнять :slight_smile:

@asolntsev, кстати, этот кусок второй из селенида брал, прикольно вы придумали урлы открывать :slight_smile:

#4

Вы подробно расписываете, КАК это сделать, но не говорите, ЗАЧЕМ.

А я думаю, что не придётся. Для этого нет по-настоящему хорошей причины.

1 лайк
#5

Причиной может быть банальное желание спонсоров видеть отчеты именно в таком виде. Не везде и не всегда автоматизация делается как вещь в себе, иногда те, кто платит деньги, хотят в том числе и понятные картинки, а не набор логов со стектрейсами.

2 лайка
#6

Кстати, да, но я не поэтому с ними связался… :slight_smile:

Я совсем недавно начал развиваться в автоматизации. Связался с аллюром, из-за того, что там сложно эти отчеты прикрутить (чтобы не все просто было и был стимул искать инфу). Позже эти отчеты оч понравились, тем что в них не только скрины можно всунуть и статус теста, но и еще кучу всяких штук нужных…

кстати, очень даже не пожалел, что связался именно с этими отчетами, пока их прикручивал, возился с разными листенерами, pom.xml - убил кучу времени и пытался понять как реализовать, многому научился :slight_smile:

Интересно, что люди используют в реальных проектах…

#7

@evgmoskalenko Учиться - это хорошо! :slightly_smiling:
Так и есть: первые три года инженер учится тому, как сделать сложно, а оставшуюся жизнь - тому, как сделать просто. Это намного сложнее!

5 лайков
#8

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

Когда работал в Яндекс.Деньгах готовился перевести свой проект именно на Allure (не успел). Общался с командой, которая этот Allure создала - отличные ребята. Если будут проблемы/глюки/баги - пишите им, не стесняйтесь - реагируют быстро и адекватно.

1 лайк
#9

Конечно, это всё не помешает, но в первую очередь нужно ЖЕЛАНИЕ делать просто. Нужна сфокусированность на простоте. Именно этого обычно не хватает, а вовсе не опыта.

#10

что-то мне кажется что ключевые моменты - “не сделать просто”, а сделать так, чтобы и код красиво выглядел и понятно было другим разработчикам, из этого вытекает - “лучше сделать проще”, видел проект один там сделали все так просто, до ужаса просто, и мне подобная реализация очень не понравилась…

аллюр решил прикрутить потому что там можно и шаги добавить без методов, а простым способом - аннотациями, через один лишь только листенер. Также можно добавить аттачменты иногда очень необходимые и т.д., но в какой-то момент, закралась мысль, что возможно это “балавство” и “няшность”, что на живых рабочих проектах мало кто такое юзает и достаточно использовать обычные отчеты и забить, что туда может зайти маркетинг, PM, PO, или еще кто

1 лайк
#11

для этого нужно очень много опыта и времени

Неоднократно наблюдал, как школота делала просто.
Это катастроффа какая-то - не имея опыта, глубокого понимания технологий и взаимосвязей, не думая о перспективах, элементарно не имея базовых знаний … школота делает всё очень просто … просто шлак или диверсию… Да ещё берётся поучать взрослого дядю. Приходится всё переделывать.

Нет уж! Научитесь сперва делать сложно, потом поймёте что и как можно упростить.

#12

А я неоднократно наблюдал, как “сениоры” делали так заумно, сложно, навороченно, что разобраться в этом было нереально, и в итоге это забрасывали и делали за два дня на коленке “чтобы хоть как-то работало”, и оно оставалось работать на долгие годы.

Вариант, когда школота делает всё просто, хорош тем, что на это потрачено мало ресурсов, и не жалко будет переделать “по уму”, когда придёт понимание, а как же это - по уму.

2 лайка
#13

Использовал его на одном проекте.
Из сложностей с Дженкинсом - только начальный процесс настройки, а дальше все работает :blush:
Использовал стандартный плагин, не CLI.

Так же сложности возникают с новыми версиями. Но тут уже … только ждать и не обновляться на бою пока не будет стабильной работы.

По тегу Allure найдете всю интересующую Вас информацию.

Это все удобно, как говорили выше, если на проекте ваши отчеты будет смотреть кто то не связанный с автоматизацией (спонсоры). Упростит разбор результатов за счет заранее продуманных и реализованных шагов, но не поможет вам если структура проекта будет слишком закрученной и в ней можете разобраться только вы, что тоже говорили выше :blush:

1 лайк
#14

Спасибо, @Artyom :slightly_smiling: по началу Allure был, как вызов, с ихней то документацией непонятной, в которой все рассчитано на опытных ребят… Потом к нему привык :slight_smile:

Скоро этап интеграции с Jenkins, чувствую намучаюсь, но от этого задача становится еще интересней…

Порадовало то, что ничего не сломалось в тестах с многопоточностью…

#15

Вот хорошая статья по использованию самого Allure

Успехов с настройкой :blush:
Ну и план Б на всякий случай :wink:

1 лайк
#16

Спасибо за статью, и план Б. На статью набрел в самом начале знакомства с Allure, и уже все из этого - сделал, получилось реализовать :slightly_smiling:

#17

дешевле и быстрее - согласен, а дальше как пойдёт
но то, что сделано просто и переделывать будет легче
так что не думайте, будто я вам пытаюсь противоречить

1 лайк
#18

А что может быть сложного с интеграцией allure Jenkins? Вот ваши тесты работают скажем на pytest.

И вы запускаете тесты в одном билдере командой в терминале:
py.test %mytest%:%TestCase% --alluredir [path_to_xml_dir]
вторым шагом полученная папка с xml’ом отдается в allure CLI:
прописываем в командной строке
allure generate [path_to_xml_dir] -o [path_to_html_dir]

1 лайк
#19

абсолютно ничего сложного, просто, видите ли …
там филосовский спор был
не про аллюр+дженкинс, а про интеграцию школота+тестирование
победил минималистичный подход:
чем меньше/проще сделают - тем меньше будет косяков, проще переделывать

ПС: да и тема слегка зачерствела, пару недель назад

1 лайк
#20

Попробуйте использовать Gradle вместо Maven. Гибкая архитектура, приятный HTML репорт, который можно подредактировать в отдельном таске под свои нужды. Я сейчас имплементирую добавление ссылки на скриншот для Фейл тестов и Console Output для каждого теста отдельно в ХТМЛ репорте. Мне нравиться концепция что все в твоих руках, и можно докрутить что тебе нада :slight_smile:

1 лайк
#21

Прикрутил Allure к дженкинс вообще никаких проблем не составило, главное было идти по их инструкции и обратить внимание на коммит на гитхабе (который также есть в инструкции)…

1 лайк
#22

Тоже используем jenkins + allure и allure python.

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

Настройка сама не сложная, все по мануалу, взлетело сразу.

Единственное, чего не хватает - это печатной версии отчета. Чтобы протокол тестирования можно было сгенерировать со скриншотами. Вот теперь думаю- то ли писать свой генератор протоколов. Или не стоит, пусть народ руками выковыривает скриншоты.