Какой-то уникальный проект, на котором API тесты медленнее, чем e2e

Может я тесты концептуально плохо пишу - идеи принимаются)) Как раз для экономии медленного API создают тестовые данные на сразу горсть e2e тестов, чтобы быстрее было. Данные создаются в @BeforeAll  - потому что тестов 6-10 которые уже быстро через ui бегают.

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

но в идеале, чтобы аллюр просто красивые логи вешала на падение в @BeforeAll, всё как мы любим

Была точно такая же проблема (оч долгое создание прекондишенов)
Решение:
Можно создавать прекондишны отдельным билд стэпом вообще и куда-то их сохранять - грубо говоря "тест-контекст" (по аналогии с ApplicationContext спринга)

Концептуально этот "контекст" - Map< id теста против созданных сущностей >.

А в тесте пробовать достать из контекста эти данные (да хоть ParameterResolver-ом) или просто Context.get...

В случае если вдруг в контексте не нашлось прекондишена для данного теста, то налету попробовать создать его еще раз (т.е. если ошибки от API по настоящему редкие и ошибка случано возникла на шаге "build test data" то и хрен с ней - тест сам себе все создаст и будет зеленый. А если уж второй раз подряд - ну тест упадет со всеми красивыми логами.)

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

Вплоть до создания тестовых данных до тестов, например по запуску сервера. Правда не хочется ещё создавать технические зависимости для хранения контекста.

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

Вот пока не надо было, но если создавать данные независимо от теста, то где хорошо хранить мэппинг?

В одном проекте использовали монгодб (для еще худшей идеи, хранения там локаторов) - это было просто ужасно

Мне спонтанно кажется, что неплохая идея сделать в своём приложении простейший эндпоинт, который простые мэпы хранит (да хотя бы и в памяти).

Упс, это не автомаейшн чат. Внезапно в оффтопик ушел, сорри.

Да, с отсутствием степа обидно, ну хоть стэктрейс цепляется, уже что-то:)

ну тут подойдет любое кейвелью хранилище. Мы подняли хазелкаст, пондимается в докере и отлично хранит кей/велью. Это я про тот подход, который Дима описывал выше, с созданием прекондишнов

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

Ну как там в шутке: у нас была проблема, мы подняли хазелкаст и теперь у нас две проблемы)

ну пока проблем не встретили, пользуемся уже давно 🙂 в яндексе помню эллиптикс был, в него складывали тоже

короче не суть в названии, суть в подходе 🙂 но в само приложение это имхо точно не стоит 🙂

Дело в майнд-сете (или грубо постановке мозгов). Вполне нормально вв pipeline раскатки окружения добавить джобу генерации тестовых данных, а следом за ней в случае успеха генерации данных - запускать джобу с тестами в этом же pipeline

deploy -> create test data -> test

Это нормально - если тестовые данные не сгенерились - это надо разбираться с настройкой окружения и багами уже.

Когда шаг генерации пройдет успешно - запускать тесты.

Тут всегда можно абстрагироваться от тестов: «тестовые данные не создались - баги уже есть, даже до тестов дело еще не дошло». Пофиксят инфрастурктуру и создание тестовых данных - тут уже вступят в работу автотесты, которые «быстрые». Вроде и хитрость, а вроде и нет 🙂

Кто-то в курсе какое значение нужно вставлять в "Issue Tracker Key" поле? Это jira-cloud

ну надо нажать open issue trackers