Отсутствие жесткой привязки к AllureID при изменениях в структуре проекта и наборе параметров.

Если у вас нет жесткой привязки к AllureID (см. более подробно в этой статье), при этом были изменения в сигнатуре метода (пакет, класс, имя метода) или наборе параметров такие что полное имя теста поменялось (например, было io.testops.IssuesRestTest.useCaseParameterizedTest, а стало io.testops.IssuesRestTests.useCaseParameterizedTest), то такой результат не может быть отнесен к предыдущему ТК, так как сигнатура не совпадает, в этом случае будет создан новый ТК.

При изменении сигнатуры метода система считает такой результат — результатом нового теста, так как привязка результата внутри ТестОпс идет или по полной сигнатуре с набором параметров или по явно указанному в коде (попадает в результат теста) атрибуту AllureID.

При изменении набора параметров: количество параметров, имена существующих параметров меняются контрольные суммы, описанные здесь и привязка к существующему AllureID нарушается.

Как избежать?

При планировании следующих изменений в коде:

• название пакета (или какого-то аналога для пакета для вашего языка программирования)

• имя класса (или какого-то аналога для класса для вашего языка программирования или тестового фреймворка)

• название метода (функции и проч)

• увеличение или уменьшение количества параметров (было 0 стал 1, был 1 стало 0 и т.д.)

• изменение имен параметров

• требуется до этих изменений внести в код теста информацию о том, какой AllureID у вашего теста. AllureID в результатах теста имеет более высокий приоритет, чем полное имя с набором параметров и результат измененного теста будет связан с корректным ТК.

Падение теста на стадии SetUp блока

Если тест падает на стадии setUp блока (например, BeforeAll, BeforeEach, before хуки или любые аналоги частей кода, которые выполняют подготовительные действия до выполнения тела теста) и при этом у него есть параметры или/и явно прописанный AllureID, то в этом случае тест, как правило, помечается как BROKEN, и до выполнения логики самого теста дело не доходит, как итог информация о параметрах, AllureID в результат такого теста не попадает и процесс сопоставления результата теста существующему ТК нарушается и создается новый ТК с новым AllureID и без каких-либо параметров.

Как избежать?

Чтобы при падении тестов на setUp блоках не происходило создание дубликатов тестов есть несколько вариантов решения, как организационные, так и технические:

Организационные меры свои

Упавшие тесты в состоянии BROKEN требуется перезапустить. Если тесты сгенерируют PASSED результаты, то они будут новыми в созданном лонче, BROKEN результаты далее потом просто можно удалить (скрыть) из лонча.

Технические меры на уровне интеграции

Запрос на добавление функционала в соответствующий репозиторий проекта Allure Framework для обработки BROKEN тестов.

Технические меры

Самостоятельная доработка функционала проекта с тестами, чтобы при падении теста на setUp блоке в результат добавлялся бы ALLURE_ID=-1 (AS_ID=-1).  В этом случае результат не будет генерировать новый ТК, но при этом будет присутствовать в результатах и информация о падении будет доступна команде.