Переезд с Allure

Если тесты уже размечены Allure-аннотациями, а связи с тест-кейсами держатся на Allure ID, адаптер подхватывает эту разметку как есть — без Allure-зависимости в classpath и без правок кода. Разметка @Doqa* — основной путь; Allure-мост существует, чтобы переехать на неё постепенно, тест за тестом, ничего не сломав по дороге.

Что работает без правок кода

Что у вас есть	Что делает DoQA
Архивы allure-results	принимаются как раньше — Отправка результатов
Метка as_id (allure_id) в отчёте	привязка автотеста к тест-кейсу один-к-одному; новая привязка этого автотеста к другому кейсу снимает прежнюю — Связь с тест-кейсами
@AllureId на тесте или классе	всегда уходит меткой as_id (привязка к кейсу) и участвует в выводе внешнего ID — см. ниже
@Epic / @Feature / @Story / @Owner / @Severity	становятся метками epic:…, feature:…, story:…, owner:…, severity:…
@Description	описание автотеста — если нет @DoqaDescription
@Link, @Links, а также @Issue и @TmsLink со значением-URL	типизированные ссылки: issue — дефект, tms — требование
Пайплайн, собирающий Allure Report	продолжает работать: файловый режим адаптера пишет Allure-совместимые артефакты

Приоритет у моста односторонний: родные @Doqa*-аннотации всегда выигрывают, Allure только заполняет пробелы.

Чем станет внешний ID

Без явного @DoqaId адаптер выводит внешний ID по строгому приоритету: маркер в имени → @AllureId → хэш сигнатуры. Из @AllureId внешний ID получается с префиксом: @AllureId("123") даёт ALLURE-123. Сам Allure ID при этом не «расходуется» — он отдельно уходит меткой as_id и делает привязку к тест-кейсу.

Ключ ALLURE-… стабилен: он не зависит ни от имени теста, ни от класса. Жить на таких ключах можно сколько угодно долго.

Как DoQA сопоставляет результат с автотестом

1. Точное совпадение внешнего ID в пространстве — результат попадает в эту запись каталога.
2. Иначе — совпадение по полному имени: если у найденной записи ещё нет своего ключа, присланный ключ «усыновляется» и история сохраняется; если ключ уже есть и он другой, запись остаётся со старым ключом, а результат всё равно попадает в неё.
3. Иначе создаётся новая запись.

Практические следствия:

• Отчитывались отчётами без ID и добавили @DoqaId — история усыновляется. Не меняйте имя теста и ID в одном коммите: усыновление ищет запись по прежнему имени.
• Уже работали с адаптером на ключах ALLURE-… и добавили @DoqaId — ключ записи не переписывается: результаты продолжают попадать в неё по имени, а внешний ID остаётся ALLURE-…. Свои ключи задавайте новым тестам до их первого прогона; за старыми надёжнее закрепить фактический ключ явно: @DoqaId("ALLURE-123") — после этого тест можно свободно переименовывать.
• Ничего не менять — тоже рабочий вариант: идентичность на ALLURE-…, привязка через as_id.

Переезд на разметку @Doqa*

Эти замены безопасны даже массовой автозаменой по проекту — на идентичность автотеста они не влияют:

Было (Allure)	Стало (DoQA)
@Description("…")	@DoqaDescription("…")
@Epic("Оплата")	@DoqaLabels({"epic:Оплата"})
@Feature("…"), @Story("…")	@DoqaLabels({"feature:…", "story:…"})
@Owner("…"), @Severity(CRITICAL)	@DoqaLabels({"owner:…", "severity:critical"})
@Link, @Issue, @TmsLink	@DoqaLink / @DoqaLinks

Полный справочник разметки — Адаптер JUnit 5.

Две замены требуют внимания:

Идентичность и привязка — не автозаменой

• @AllureId → @DoqaId — смена источника идентичности; последствия описаны в разделе выше. Для тестов с накопленной историей закрепляйте фактический ключ (@DoqaId("ALLURE-123")), а не выдумывайте новый.
• Привязку через Allure ID заменяйте на @DoqaCaseIds({…}) или на совпадение кода тест-кейса с внешним ID. Снятие @AllureId уже созданные связи не рвёт, но новые привязки этим способом перестанут создаваться.

Смотрите также

• Адаптер JUnit 5 — установка, конфигурация, полный справочник аннотаций
• Автотесты — внешний ID и способы привязки к тест-кейсам
• Отправка результатов автотестов — приём готовых allure-results