Мы сначала тоже вытянули эти идентификаторы на пользовательский слой, но потом оказалось, что это было [очень] неудачным решением.
Пользователи не понимали, что это за число, появлялись дубликаты одного кейса с разным содержимым, история запусков ломалась и прочее.
С учетом того, что опс в целом успешно справляется с матчингом тестов по имени и содержимому, мы нашли нормальным решением убрать из кода идентификаторы.
А с механизмом создания и поддержания локов
dependencyLocking{ lockAllConfigurations() }, устанавливающим отношение зависимость-[конфигурации], не будет конфликтовать автоупорядочение и автоподтягивание?
@AllureId это номер тесткейса по сути в БД опса.
Мы сначала тоже вытянули эти идентификаторы на пользовательский слой, но потом оказалось, что это было [очень] неудачным решением.
Пользователи не понимали, что это за число, появлялись дубликаты одного кейса с разным содержимым, история запусков ломалась и прочее.
С учетом того, что опс в целом успешно справляется с матчингом тестов по имени и содержимому, мы нашли нормальным решением убрать из кода идентификаторы.