Какими SQL запросами обычно работают с тестовыми данными

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

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

Как отвечать

Сгруппируйте запросы по задачам тестировщика, а не по буквам CRUD:

• проверка результата: SELECT с JOIN после действия в интерфейсе или вызова API. Выбирайте нужные колонки и точное условие, а не SELECT * по всей таблице;
• поиск аномалий: дубли через GROUP BY email HAVING COUNT(*) > 1, «сироты» через orders LEFT JOIN users ... WHERE users.id IS NULL, распределение по статусам через COUNT и GROUP BY;
• подготовка данных: INSERT с RETURNING id в PostgreSQL, массовое заполнение через INSERT ... SELECT и generate_series;
• перевод в нужное состояние: UPDATE, чтобы не ждать неделю, пока истечёт подписка: UPDATE subscriptions SET expires_at = now() - interval '1 day' WHERE user_id = 42;
• очистка: DELETE по признаку тестовых данных или TRUNCATE на своём изолированном стенде.

Хороший тон: помечать свои данные (префикс в email, отдельный флаг), чтобы удалять ровно их, и оборачивать эксперименты в транзакцию: BEGIN, изменения, проверка, ROLLBACK. В автотестах данные чаще готовят через API или фикстуры, а SQL остаётся для проверок и состояний, которые через интерфейс не получить.

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

Пишут UPDATE или DELETE без WHERE на общем стенде. Сначала выполните тот же запрос как SELECT с тем же условием и посмотрите, сколько строк он задевает.

Сравнивают с NULL через =. Условие WHERE deleted_at = NULL не вернёт ни одной строки, нужно IS NULL.

Считают TRUNCATE быстрым DELETE. Он не принимает WHERE, упирается во внешние ключи (в PostgreSQL нужен CASCADE), а в MySQL выполняет неявный коммит и транзакцией не откатывается.