вместо создания Vasya Pupkin создавай Vasya_successful_login_xhgt Pupkin

один префикс дает понимание для какого сценария были созданы эти данные, другой префикс - на случай, если 2 таких теста работают одновременно

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

докер это вопрос перпендикулярный к окружению dev/stage, потому что бекенд в докере фактически может подниматься в любом из окружений, используя разные файлы конфигурации.
В моем текущем проекте устроено так: веб тесты во время их разработки гоняются на локалхосте (моя рабочая машина, на которой также запускается бекенд), после создания Pull Request в основную ветку проекта, тесты запускаются по триггеру на это событие в CI, на CI агенте используется конфиг docker-compose (он несколько отличается от локального конфига, но аналогично поднимает сервер на агенте).

Если вам интересна исключительно ситуация, когда есть какой-то общий тестовый контур, например персистентные агенты на которых крутится dev / staging бекенд, то в таком случае думаю стоит рассмотреть такой вопрос:
- ваши веб тесты активно меняют базу? (например, это могут быть скрипты миграции по накатке тестовых данных \ их очистка)
- ваши тесты всегда создают уникальные тестовые данные? как несколько запущенных тестовых сессий смогут работать в параллели? как отработают 2 теста, где один удаляет данные корректного юзера, а другой пытается к ним обратиться?
- истощается ли ваша база \ переполняется ли при N прогонов тестов (наиболее вероятно, что тестируемость от этого может пострадать), если вы используете настоящие данные базы из снепшота с продакшн базы.
- как часто предполагается делать restore операции базы? предполагается ли фейловер чтобы не терять доступность данных для контура?
вот то окружение, которое умеет решать эти вопросы и будет более предпочтительным для прогона веб тестов. выбор контура окружения станет проще, когда тесты не гонятся в параллели.

в конце концов, дев\стейдж это всего лишь тэги стадий разработки, а ответы от WEB UI тестов могут быть полезными в самом начале разработки, нет смысла их откладывать на самый конец, если вы не ужаты в ресурсах на прогоны тестов и мощности.

вот тут почитай мой пост и вопросы на которые ты хочешь понять что происходит с тестовыми данными у тебя

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

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

например, тебе для теста нужен юзер.

у тебя где-то в фикстуре создается юзер, его ID записывается в таблицу autotests_foreign_ids_track формата:

table_name foreign_id
"Users" "user_id"
"Carts"  "cart_id"

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

for entry in entries:
   table_name, foreign_id = entry
   formatted_query = f"delete from {table_name} where id={foreign_id}"
   con.execute(formatted_query)

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

1. Избавиться от хардкода
2. Ассоциировать тестовые данные с конкретным тесткейсом
3. По мере внесения данных для тесткейса также иметь таблицу, по которой можно будет найти только что созданные данные
4. чистить данные*

чистка может быть влоб (транкейт базы)
чистка может быть по одной записи на запрос
а может быть и более корректный и эффективный запрос когда ты с autotests_foreign_ids_track поработал и у тебя на кажду таблицу получились запросы:

delete from Users where id in (%user_id_for_login_test%, %user_id_for_add_to_cart_test%, ..., ..., ...)
delete from Cart where id in (%cart_1%, %cart_2%_

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

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

Не можешь создать идентичного пользователя с нуля, используй АПИ как и ты и сказал, только в случае с апи тебе нужно передавать уникальные какие-то данные, которые каждый раз будут чуть чуть но другие (не затрагивая при этом функциональность теста)

Понял, спасибо всем

Драсте, подскажите, можно ли мне валидировать json по схеме, типа

"type": "array",
"properties": {
"name1": {
  "type": "string"
},
"name2": {
  "type": "string"
},
}

Если у меня количество и имена полей name неопределено (неважно)

т.е. список может быть name1='qwe', name2='dawd', imya='dwad'. И все это будет валидными данными

Чем ты валидируешь?

jsonschema

Привет! Попробуй делать проверки на required поля. Если использовать джсон схемы. То там можно использовать для проверки additionalItems и unique type

Я её тыкал, заебался и просто использовал другие либы, подружелюбней

пайдентик?

океееей, спасибо за наводку )

В закрепе 17 пункт, ищи data validation и там пачка разных