Николай, названия коммитов просто прекрасны, было бы еще круче, если бы вы упаковывали коммиты по видеоурокам в пулл реквесты. 😊

Привет.

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

...с первого раза все должно упасть

Возможно ли использовать те же файлы миграций, но для тестовой базы данных?
Или использовать alembic для нескольких бд, как сделал товарищ тут или как описано в документации?

[DEFAULT]
# all defaults shared between environments go here

sqlalchemy.url = postgresql://scott:tiger@hostname/mydatabase


[schema1]
# path to env.py and migration scripts for schema1
script_location = myproject/revisions/schema1

[schema2]
# path to env.py and migration scripts for schema2
script_location = myproject/revisions/schema2

[schema3]
# path to env.py and migration scripts for schema3
script_location = myproject/revisions/db2

# this schema uses a different database URL as well
sqlalchemy.url = postgresql://scott:tiger@hostname/myotherdatabase

Пример миграций от Яндекса.

Грубо говоря сделать так: когда запускаешь тесты, то будут использованы все те же миграции, но на тестовую базу данных.
Это дает нам большую схожесть между тестовой средой и боевой, но с разным адресом базы данных, только и всего.

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

settings.py - идентичный существующему:

...
REAL_DATABASE_URL = env.str(
    "REAL_DATABASE_URL",
    default="postgresql+asyncpg://postgres:[email protected]:5432/postgres",
)  # connect string for the real database

TEST_DATABASE_URL = env.str(
    "TEST_DATABASE_URL",
    default="postgresql+asyncpg://postgres_test:[email protected]:5433/postgres_test",
)  # connect string for the test database

tests/conftest.py:

...
@pytest.fixture(scope="session", autouse=True)
async def run_migrations():
    # только накатывание миграций - без генерации папки tests/migrations на данном этапе
    os.system('alembic -n test revision --autogenerate -m "test running migrations"')
    os.system("alembic upgrade heads")
...

migrations/env.py:

db_name = config.config_ini_section # active config ini section is the db name that we have chosen
config.set_main_option(
    "sqlalchemy.url",
    f'{os.environ["SQLALCHEMY_DATABASE_URL"]}/{db_name}'
)

migrations/alembic.ini - пример отсюда и отсюда:

...
databases = prod, tests
[prod]
sqlalchemy.url = postgresql://postgres:[email protected]/postgresql
# если желаешь использовать отдельные подпапки для миграций
version_locations = ./migrations/prod
[test]
sqlalchemy.url = postgresql://postgresql_test:[email protected]/postgresql_test
# если желаешь использовать отдельные подпапки для миграций
version_locations = ./migrations/test
...

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

P.S. Я попробую протестировать при возможности и исправить данный issue, добавив актуальные изменения.

https://github.com/luchanos/luchanos_oxford_university/blame/82f03c7a2508e436e81b916f79ee978e3c7c769c/api/actions/user.py#L66

Check if PortalRole.ROLE_PORTAL_SUPERADMIN in current_user.roles: instead of target_user.roles:. It deprecates all actions for SUPERADMIN when we check permissions.