Что используется для работы с базой данных для упрощения тестирования

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

Умеете ли вы делать тесты, которые не зависят от того, что кто-то оставил в базе вчера. Вопрос почти всегда про автоматизацию: как вы готовите данные, как изолируете прогоны и как проверяете результат не только по экрану, но и по записи в таблице.

Как отвечать

Разделить задачу на четыре части:

• подготовка данных: фикстуры и фабрики вместо ручных INSERT, генераторы значений для полей, которые должны быть уникальными. Сущности лучше заводить через API продукта: тогда они проходят валидацию и остаются согласованными;
• изоляция: свой набор данных на каждый тест, уникальные ключи вместо общих, отдельная схема или отдельная база на поток, транзакция с откатом там, где тест и приложение работают в одном процессе;
• разворот среды: миграции (Flyway, Liquibase, Alembic) на чистую базу плюс контейнер с той же СУБД и той же версией, что на проде, поднимаемый на время прогона;
• проверки: прямой запрос к базе как утверждение теста, когда результат действия не виден в интерфейсе, например запись в журнале или проставленный статус.

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

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

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

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