Как контролировать изменения в структуре базы данных, чтобы тестовые данные и тесты не ломались

Что проверяют

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

Как отвечать

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

• миграции в репозитории: Liquibase или Flyway, изменения схемы идут скриптами рядом с кодом и накатываются на тестовую базу тем же инструментом, что и на прод. Ручные правки стенда запрещены;
• тестовые данные рядом со схемой: сиды хранятся отдельными наборами изменений (в Liquibase их удобно пометить context или labels, во Flyway вынести в отдельную locations), либо тест создаёт свои данные сам через API или фабрики объектов;
• одноразовая база: Testcontainers поднимает чистый PostgreSQL в контейнере, прогоняет миграции, тест заполняет нужное. Нет общей базы, которую кто-то уже испортил;
• миграции в CI: каждый PR прогоняет миграции на пустой базе и на обезличенной копии прода, плюс validate у Flyway или Liquibase ловит правку уже применённого скрипта;
• обратная совместимость: схема меняется по шаблону expand/contract. Сначала добавляют новую колонку, потом переводят код и тесты, и только отдельным релизом удаляют старую;
• договорённость с разработкой: PR с миграцией в том же PR правит фикстуры и тесты, а QA стоит в ревьюерах таких изменений.

Где спотыкаются

Пишут в автотестах прямые INSERT с перечислением колонок и жёсткими id. Любое изменение схемы ломает десятки тестов разом. Создание данных через API или билдеры переживает такие правки гораздо спокойнее.

Надеются на откат миграции. Удалённую колонку с данными откатом не вернуть, поэтому надёжнее миграции только вперёд и бэкап перед применением.

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