×

Automated GUI testing: пошаговая инструкция

C развитием IT-проекта растет и количество тестов продукта. Мануальное тестирование требует все больше времени, и рано или поздно команда разработки начинает задумываться над автоматизацией тестирования. Я хочу рассмотреть популярный и эффективный инструментарий для внедрения автоматизации тестирования в процесс разработки.

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

Тестирование — это неотъемлемая часть разработки ПО, цель которой — своевременное представление информации о качестве продукта группе заинтересованных лиц. Автоматизация тестирования — часть процесса тестирования с использованием программных средств для выполнения тестов и проверки результатов.

Главная цель автоматизации — ускорить процесс тестирования без потери качества, а также избавить ручного тестировщика от рутины прохождения регрессионных сценариев, позволив сфокусироваться на проверке бизнес-логики приложения с точки зрения конечного пользователя.

Преимущества автоматизации тестирования

  • Исключен человеческий фактор. Автоматизация гарантирует, что тест-скрипт всегда будет выполнен одинаково, исключая ошибки по неосторожности.
  • Скорость выполнения — время выполнения автоматизированного тест-скрипта в разы меньше ручного прохождения.
  • Меньшие затраты на поддержку — единожды написанные скрипты требуют намного меньше времени на поддержку и анализ результатов.
  • Отчеты — в результате прогона генерируется отчет с последующей рассылкой всем заинтересованным лицам.
  • Выполнение тестов в удобное время — автотесты могут быть запущены в любое удобное время или по определенному событию. Часто это ночные прогоны и тестирование в нерабочее время, что позволяет рациональнее использовать тест-ресурсы.

Уровни тестирования

Существует несколько уровней тестирования:

  • Unit tests;
  • Integration tests;
  • GUI tests;
  • Manual tests.

Unit и Integration tests оставим разработчикам, с Manual тестами все понятно. Давайте остановимся более подробно на GUI-автоматизации, набирающей популярность огромными темпами.

GUI-автоматизация — наиболее распространенный вид автоматизации тестирования путем тестирования приложения через графический интерфейс пользователя (GUI). Главное его преимущество в том, что приложение тестируют точно так, как его будет использовать конечный пользователь. Также этот подход позволяет тестировать без доступа к исходному коду приложения.

Место автоматизации GUI в процессе разработки

Для успешного тестирования с применением автоматизации необходимо определиться с местом автотестов в процессе разработки. Поскольку при помощи автоматизации GUI покрываются в основном регрессионные сценарии, то есть смысл запускать тесты для каждой новой сборки. Для этого мы используем Jenkins. После каждого успешного билда автоматически стартует сборка проекта с тестами. Также есть возможность ручного запуска или по расписанию, для запуска тестов ночью — в момент минимальной нагрузки на тестовые стенды.

Инструменты для автоматизации GUI

Путем проб и ошибок мы в Ukad пришли к следующему инструментарию для GUI автоматизации:

  • Java — как язык для написания тест-скриптов.
  • Maven — для сборки проекта.
  • Selenide — как фреймворк для написания GUI тестов.
  • TestNG — как фреймворк для управления запуском тестов.
  • Selenoid — для непосредственного управления сессиями браузера.
  • Allure — для создания и эффектной презентации отчета.
  • Jenkins — для непрерывной интеграции тестов в процесс разработки.

Более подробно об инструментах и причинах, почему мы выбрали именно этот набор:

  • Java. Мы используем Java, так как это путь наименьшего сопротивления ведь сообщество просто огромно, что дает доступ к большому количеству готовых решений для тестирования и не только. Это в свою очередь позволяет не тратить много времени на исследование и решение часто возникающих проблем, так как очень велика вероятность того, что решение уже найдено.
  • Maven. Можно использовать любой другой сборщик. Для автотестов это не принципиально, но лично мне Maven ближе.
  • Selenide позволяет не изобретать свой велосипед для решения стандартных проблем Selenium (таких как ожидания и поиск элементов на странице, добавление «мягких» проверок и т. д.) и значительно повысить скорость разработки и стабильность тестов.
  • TestNG. Мы перешли с Junit на TestNG для использования наборов на основе .xml файлов, а также возможности объединения тестов в группы.
  • Selenoid. Мы используем Selenoid вместо Selenium Hub, так как он более стабилен и позволяет запускать сессии браузеров в Docker контейнерах, плюс добавляет такие приятные бонусы, как просмотр выполнения конкретного теста и запись видео его прохождения.
  • Allure. Позволяет значительно расширить возможности стандартного TestNG отчета, эффектно и удобно презентовать всю информацию о пройденных сценариях. В репорте каждый член команды сможет найти для себя полезную информацию. Начиная от времени и количества пройденных сценариев с результатами прохождения, до прикрепленного видео прохождения и скриншотами для упавших тестов.
  • Jenkins. Мы используем Jenkins для сборки некоторых своих проектов, поэтому мы решили использовать его же для сборки тестов. Также с Jenkins удобно интегрировать Allure репорты при помощи дополнительного плагина.

Пример использования GUI автоматизации

Создаем проект с тестами

Рассмотрим, как используется GUI автоматизация на примере простого теста. Для этого создадим Maven-проект и подключим необходимые зависимости для Selenide, TestNG и Allure. Добавим простой тест, который будет открывать главную страницу сайта и проверять, что футер отображается. Для написания теста используется PageObject паттерн. Для управлением драйверами браузера используется WebDriverManager.

Актуальный pom.xml и исходный код проекта доступен по ссылке.

Проект может быть запущен командой "mvn test" (Maven должен быть установлен и добавлен к системным переменным). Все работает, но тест будет запущен в локальном браузере, а нам необходимо запускать на тестовом стенде. Самые популярные варианты удаленного запуска тестов — Selenium hub и Selenoid. Остановимся подробнее на Selenoid.

Selenoid

Selenoid — это имплементация Selenium hub кода, использующая Docker-контейнеры для запуска браузера, что позволяет нам не задумываться об управлении браузерами и сессиями. Для каждого теста будет запущен свой Docker-контейнер, который будет остановлен после окончания теста. После установки Selenoid (по ссылке доступна подробная инструкция по установке) нам только остается подправить код создания драйвера на код предложенный Selenoid.

Снова запустим наш проект командой “mvn test”.

Тест работает. Но что если мы хотим видеть выполнение теста? Для этого достаточно добавить дополнительный параметр в создание браузера и использовать Selenoid контейнеры с поддержкой VNC, например “selenoid/vnc:chrome_66.0” для 66 версии Chrome. Также нужно добавить дополнительную Capability к созданию браузера “browser.setCapability("enableVNC", true);”.

Вот так выглядит browser.json после обновления. Для простоты я оставил только Chrome 66 версии.

Также добавим дополнительную Capability к созданию драйвера “browser.setCapability("enableVNC", true);”.

Запустим наш тест еще раз и перейдем на вкладку «Session». Теперь мы можем следить за выполнением теста.

Но для эффективного использования автотестов необходима непрерывная интеграция с процессом разработки. Для этого мы используем Jenkins.

Jenkins CI

Jenkins — проект для непрерывной интеграции с открытым исходным кодом, написанный на Java. Используется для сборки и поставки программного обеспечения. У нас есть возможность использовать Jenkins для запуска тестов для каждой новой сборки тестируемого продукта. Для создания тестовой сборки нам необходимо установить дополнительные плагины:

Создадим новую Jenkins job с типом «Maven project».

Добавим наш репозиторий с тестами в секцию «Source Code Management».

Для генерации Allure отчета добавим «Post-build Actions» -> «Allure report».

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

А вот и Allure отчет.

Финальная стадия интеграции — связываем нашу тестовую сборку со сборкой нашего тестируемого приложения путем добавления в «Build Triggers» — > «Project to watch».

Таким образом после каждой успешной сборки тестируемого проекта мы автоматически запускаем сборку тестов. Остается только оповестить о результатах теста заинтересованную группу людей путем отправки Email или Slack-уведомлений.

Полезные ссылки

Вывод

По мере усложнения кода, добавления нового функционала и исправления багов, процесс тестирования будет занимать все больше времени. Команда мануального тестирования физически не сможет успевать за ритмом команды разработчиков. Ведь проверка нового функционала — это не только функциональные тесты, но и ресурсоемкие регрессионные прогоны. Внедрение автоматизированного тестирования позволяет снять с команды мануального тестирования достаточно объемную часть регрессионных прогонов. Но следует помнить, что ни полная автоматизация, ни стопроцентное ручное тестирование не дадут гарантии идеального результата. Оптимальным подходом в данном случае является разумный баланс.

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

Использование связки автоматизированного и ручного тестирования и тесное взаимодействие с командой разработчиков от начала процесса работы над проектом до его реализации повысит качество конечного продукта.

Эта статья также доступна на английском.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному4
LinkedIn

Схожі статті




61 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Я прям невдупляю что я только что прочитал?! И это статья автора уровня lead qa automation?!
имхо 30% статьи ересь!
p.s. шо за ппц уровни тестирования gui, manual?! автор что ты гонишь?! налей и мне!

Баги также конструктивно описываете?

Автор, поработай автоматизатором хоть пару лет, а тогда начинай писать такого рода статьи, а то у меня слезы наворачиваются...

Когда перестанете плакать и хамить, можете описать свое видение обзора инструментов более аргументированно? А не на уровне ученика 8 класса...

«Исключен человеческий фактор. Автоматизация гарантирует, что тест-скрипт всегда будет выполнен одинаково, исключая ошибки по неосторожности.»
И возникает эффект пестицида

«Скорость выполнения — время выполнения автоматизированного тест-скрипта в разы меньше ручного прохождения.»
Зато написание и поддержка не факт что меньше

«Меньшие затраты на поддержку — единожды написанные скрипты требуют намного меньше времени на поддержку и анализ результатов.»
В денежном эквиваленте может даже быть больше, зависит от проекта. На ЗП автоматизатора можно взять 3 ручников.

«Отчеты — в результате прогона генерируется отчет с последующей рассылкой всем заинтересованным лицам.»
В большинстве случаев бесполезны «для всех заинтересованных», кроме автоматизатора. Нестабильные тесты и новая или измененная функциональность у непосвященных ПМов срывает крышу.

«Выполнение тестов в удобное время — автотесты могут быть запущены в любое удобное время или по определенному событию. Часто это ночные прогоны и тестирование в нерабочее время, что позволяет рациональнее использовать тест-ресурсы.»
Приходите и разбираете чего упали тесты, в результате оказывается что ночью devops что то меняли, упала сеть, отключили электрику, испортилась погода на Марсе. Опять же все зависит от проекта.

Я просто хотел сказать, что автоматизация не всегда нужна и не всегда полезна. И у каждого утверждения есть скрытые и иногда существенные нюансы.

Всё хорошо написали. Люто плюсую TestNG и Allure. Но конфигурить Jenkins через веб интерфейс в 2018 году — дурной тон. Jenkins pipeline позволяет хранить конфигурацию билда в пристойном виде в репозитории. А multibranch pipeline plugin — удобнее работать с несколькими ветками, пулл-реквестами и интегрироваться с git/Github. Selenide — обёртка на любителя, особых преимуществ у нее по сравнению с нативными Selenium Page Objects нет, а ограничения — иногда досадные (неспособность конфигурить implicit timeout, например). По Selenoid — видео капчурить и браузеры в докере умеет и стандартный образ от github.com/...​eleniumHQ/docker-selenium . Он и обновляется регулярно. Единственное возможное преимущество Selenoid — это Selenium Hub написаный на Go. Однако актуально это становится, когда одновременных параллельных сессий больше пятнадцати-двадцати, чего при нормальной организации test flow происходить не должно.

спасибо за коммент,

Но конфигурить Jenkins через веб интерфейс в 2018 году — дурной тон.

это тема для отдельной статьи. Описывать здесь Pipline — только растягивать статью и путать новичка, ИМХО.

Selenide — обёртка на любителя

 — на вкус и цвет все фломастеры разные, но ИМХО Selenide экономит намного больше времени чем будет затрачено на добавление ожиданий к элементам где это необходимо через: "$("someElement").waitUntil(Condition, timeout);"

видео капчурить и браузеры в докере умеет и стандартный образ от github.com/...​eleniumHQ/docker-selenium .

на момент выбора docker реализации, selenoid показался более стабильным в плане управления сессиями, скорее всего что-то уже изменилось у docker-selenium

$("someElement").waitUntil(Condition, timeout);

Согласен, фломастеры — разные.
Но использовать строки каждый раз при обращении к элементу — нехорошо.
Оно и выглядит гадко, и рефакторить локатор с текстом внутри строки не удобно.
В связи с этим очень кстати пришлись extension methods + default arguments в Groovy/Kotlin.
Гораздо приятнее стало и код читать и рефачить.
someElement.customWait()
Можно ваять page object с Selenide, но кажется, так мало кто делает в реальной жизни. И сколько не смотрю на их примеры selenide.org/...​ntation/page-objects.html — всё равно нативные лучше кажутся.

С Web-ом всё понятно. Можете что-то посоветовать для OpenGL / DirectX разработки? Какими инструментами посоветуете тестировать UI в 3D сценах?

Я думаю, что для OpenGL/DirectX будет достаточно инструментов тестирования, как токо они станут декларативными :) А так обращайтесь к авторам game-engine, например unity. А если свой движок используете — то клава вам в руки.

Дельная статья.

Главная цель автоматизации — ускорить процесс тестирования без потери качества, а также избавить ручного тестировщика от рутины прохождения регрессионных сценариев, позволив сфокусироваться на проверке бизнес-логики приложения с точки зрения конечного пользователя.

Я бы добавил , чтобы дать возможность ручным тестировщикам провести exploratory тестирование и в том числе выполнить проверки которые нету смысла автоматизировать.

Исключен человеческий фактор. Автоматизация гарантирует, что тест-скрипт всегда будет выполнен одинаково, исключая ошибки по неосторожности.

Это и одноврменно недостаток, так как тест будет прогонятся всегда одинаково — возникает парадокс пестицида, когда на других тестовый проверках и данных могут проявится баги . Но если имеется ввиду что просто исключается человеческий фактор то ОК :)

Уровни тестирования
Существует несколько уровней тестирования:

Unit tests;
Integration tests;
GUI tests;
Manual tests.

А как же API? Часто возникает неободимости покрывать тестами этот уровень, особенно если реализация Гуя вообще не предполагается. Мануал тесты я бы вообще не относил бы к уровням. Это отдельный вид которым можно покрыть и gui и api и integration.

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

Web UI тесты зачастую сыпятся как штукатурка в заброшенном доме культуры.

в большинстве случаев это сигнал о том. что у вас проблемы в первую очередь в тестах

Меньшие затраты на поддержку — единожды написанные скрипты требуют намного меньше времени на поддержку и анализ результатов.

Вот это не надо ляля, затраты на поддержку еще какие. Особенно если единожды, то есть без рефакторинга и как сложилось.

Из положительного в последнее время появление тулзов типа cypress, что хоть делает эту поддержку чуть менее беспросветной.

Не нужно писать «как сложилось» и без рефакторинга. Необходимо раз, но по-человечески и довести тесты до стабильного выполнения для исключения случайных сбоев которые не считая сбоев по связи в 99% случаев имеют четкую причину которую возможно найти. Перестать городить велосипеды, а использовать зарекомендовавшие себя инструменты. Также не стоит крыть тестами все и вся, а только устоявшийся на данный момент функционал. И про боль поддержки тестов можно будет забыть. А умеючи. можно и лом согнуть....

А умеючи. можно и лом согнуть...

вот только сопровождаемых UI тестов в дикой природе с огнем не сыщешь. Обычно проще выбросить и заново написать. В более удобном инструменте. А Дженкинс прикрутить как бы такое.

Обычно проще выбросить и заново написать

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

Какой смысл переписывать тесты если не было изменения бизнес логики.

что, батарею тестов никогда наследовать не приходилось? Когда падает непонятно что и почему. Не говоря уже об архитектурных сдвигах и постоянных изменениях, которые таки тоже постоянно происходят.

Ежели ваши тесты так хорошо и легко сопровождаются в динамической среде — ждем продолжения серии о секретах и техниках подобного.

Наследовать и создавать с 0 это 2 совсем разные ситуации. Наследство, понятно что проще переписать в 99% случаев.

А секрет легкого сопровождения банален и прост. Чём меньше тестов , тем проще поддержка. Не стоит плодить телегу из UI тестов. Разумный баланс интеграционных и UI поможет, но это тема совсем другой статьи. Да и сломано в этом вечном холиваре 100500 копий.

Главная цель автоматизации — ускорить процесс тестирования без потери качества, а также избавить ручного тестировщика от рутины прохождения регрессионных сценариев, позволив сфокусироваться на проверке бизнес-логики приложения с точки зрения конечного пользователя

Вот вообще мимо. Цель абсолютно другая. Хотя если для вас это важно то ок )

Если все настолько противоположно у Вас, поделитесь — всем будет интересно. Для нас важно ускорение процесса тестирования без потери качества, а с его повышением. Уменьшение времени на прогоны регрессионных тестов позволяет использовать его более рационально.

Ну наверное стоит говорить об улучшении атрибутов качества? Возможно важны быстрые релизы? Возможно дать быстрый фитбек девам о внесении изменений?)

ускорить процесс тестирования без потери качества,
Возможно важны быстрые релизы? Возможно дать быстрый фитбек девам о внесении изменений?

спасибо что перефразировали =)

Обращайтесь) мы же инженеры ) И должны если не быть, то хотябы говорить как они)))))

так то ты переобутый инженер и твою гуманитарную закваску никакой хирэ не испортит)))

Возможно говорить сложно о простом это не быть инженером. Возможно это присуще тем кто не знает о чем говорит или просто выпендривается?
А вот рассказать просто о сложном это уже надо уметь)

Возможно говорить сложно о простом это не быть инженером

Ну если вам все просто — ок)

Коллега, эти вещи известны даже начинающим автоматизаторам. Все равно что рассказывать девелоперам об операторах в программировании.
Если подразумевалось чтобы именно разрабы посмотрели и начали писать UI автоматизацию, то это сомнительная идея.
1. Мотивация у девелопера пропадает после первых написанных тестов, т.к. дальше все выглядит сравнительно однообразно.
2. Нужны знания теории тестирования даже если писать автотесты на основе готовых мануальных тест-кейсов, т.к. они редко реализуются идентично.
3. Нужно много времени.

«Статья будет полезна не только менеджерам, отвечающим за процессы разработки и тестирования, но и рядовым тестировщикам. Ведь нет такого тестировщика, который не хочет стать автоматизатором.» — часть вступления.

Статья — обзор инструментов и места автотестов в процессе разработки, Бывалые автоматизаторы давно прошли этот путь.

Бывалые автоматизаторы давно прошли этот путь

И по этому не пишут на Java))))

На чем же пишите коллега? На чистом питоне или селениум ide? Какой посоветуете стек технологий?

пишуть, пишуть) Ще й як пишуть — бо інструмнетів для Java значно більше ніж для всіх інших мов разом взятих)

Есть ребята которые выглядят как очень ухоженные дровосеки, так им котлин или гоу подавай ! Тфу!!! Срамота !

Я пишу на колин и груви в добавок к жаве) но борода не растёт ;(

это из за джавы не растет, ну и наверное потому что ты смузи со спирулиной не пьешь

Добавь в стек еще java script И сразу и борода и походы в барбершоп появятся. Ну еще для всего прочего можно для мобильных приложений писать тесты отдельно Kotlin Для Android и Swift для iOS...
Правда у меня даже так борода не растет ;)

Коллега, эти вещи известны даже начинающим автоматизаторам. Все равно что рассказывать девелоперам об операторах в программировании.

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

Для тех кто воодушевился данной статьей, помните, UI тесты вносят огромный технический долг, у них бесконечно долгий feedback loop, 90% функционала который вы ими покрываете можно мигрировать на уровень unit/integration тестов.

Истинно так =) на эту темы огромное кол-во статей и докладов. Пирамиду автотестов никто не отменял

Открою вам тайну : технического долга не существует, если вы его не берете взаймы)))))

Влад, пирамиды тоже не существует))))

Да! Да! Но нет! =)
Согласен на 100500 с тем что нужно переносить львиную долю UI тестов в API(подразумеваю api веб-сервисов).

Unit тесты вообще прекрасно! Это ведь те что пишут разработчики на свой код? Просто убедиться что мы об одном и том же говорим.
Не знаю правда как в таком случае вы предлагаете их писать... ведь проект может делать много команд на разных технологиях... да и какой же должен быть скил у тестировщика чтобы он мог писать Unit тесты на код разрабочика.

Integration тесты... тоже нужно определиться о чем идет речь.
Допустим есть метод в исходном коде проекта который ходит в БД.
Тест написанный на этот метод уже будет интеграционным.

Просто много докладов/статей на эту тему. Но все они на примере «Hello world» и оторваны от реальной жизни.

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

Да, обычно юнит тесты сами разработчики и пишут. Хотя, если не сложная функциональность, то можно написать базовый класс, замокать внешние ресурсы, запилить пару тестов для примера, после чего дать тестировщику дописывать простыню типовой копипасты.

Если вы не хотите тестить БД, то мокаете и тест на один метод быстро становиться Unit, а тестировать внешние системы/данные — это вообще гиблое занятие — никогда не знаешь, что посыпится

Підтримую. Враховуючи, що для покриття API базовими тестами наразі достатньо постмана і знання основ js, одразу пилити кейси для UI-рівня — дорого і довго, та і зафейлений тест є недостатньою інформацією для репорту, зазвичай реальні причини ховаються на нижчих рівнях.

Почему все пытаются выбирать что-то одно? Тесты API — это тесты API, тесты UI это тесты UI и у каждого вида тестов свое место и степень покрытия. Не стоит пытаться покрыть одним типом теста все и вся... UI и API тесты прекрасно сосуществуют и дополняют друг друга, но не стоит забывать что API тестов должно быть больше. Если крыть все UI тестами то боль и разочарование обеспечены

Згоден, конкретизую: чомусь всі статті для автоматизаторів початкового рівня зводяться до написання тестів для UI, оминаючи взагалі API рівень. Якщо ж поєднувати — набагато простіше локалізувати проблему. Саме це і було метою коменту.

Тому, що API — це всякі REST/SOAP, http, get/put/delete/post, xml/json і тп. Складно. А UI — «Пишемо button.click() і дивимось як натиснулась кнопочка» :)

Когда напишешь свою статью про

це всякі REST/SOAP, http, get/put/delete/post, xml/json і тп. Складно.

Сбрось пожалуйста на неё ссылочку!
Заранее спасибо:)

Сколько людей столько и мнений, пару комментами выше коллега писал, что API тесты просто, основы JS + Postman. Вам сложно) Как по мне. так все сложно, если качественно, а не вжух-вжух и в продакшен =)

Спасибо за интересную статью Влад. Возник только один вопрос — как у фреймворк работает? Насколько я вижу неправильно прописана зависимость — allure-maven в reporting . Или я ошибаюсь? Заранее спасибо за ответ

Спасибо,а что именно вызывает сомнения?

У меня не подтягивает allure-maven в плагинах. И насколько я вижу в документантации написано что данная секция должна быть написана в билд секции — Add following lines into your pom.xml build section: github.com/...​re-framework/allure-maven

Расположение выбрано в соответсвии с рекомендациями из оф, документации maven.apache.org/pom.html#Reporting, формирование отчета относится к стадии Site соответсвенно и зависимости подтягиваем в эту секцию.

Что значит не подтягивает? по mvn clean test site что происходит? дайте текст ошибки. Если используете тестовый проект который прикреплен к статье, обратите внимание что необходимо заменить URI в классе «MyDriverManager» на актуальный.

[ERROR] No plugin found for prefix ’allure’ in the current project and in the plugin groups [org.apache.maven.plugins, org.code
haus.mojo] available from the repositories [local (C:\**********\.m2\repository), central (https://repo.maven.apa
che.org/maven2)] -> [Help 1] Да я использую тестовый проект который прикреплен к статье. Тест проходит все ок, не работает именно аллюр репортинг так как в поме он находиться не в секции билд.(Add allure-maven-plugin to your pom.xml file build section. — так написано в документации) Когда перенести в секцию билд это —
io.qameta.allure
allure-maven
${allure-maven.version}

то алюр работает

Странно, не сталкивались с этой проблемой ни у меня ни на других машинах на которых запускали. Но спасибо, надо будет посмотреть на досуге, мб найду причину.

Підписатись на коментарі