Напиши SQL запрос для добавления записи в таблицу location

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

Для тестировщика INSERT это не синтаксис, а подготовка данных на стенде. Смотрят, спросите ли вы про структуру таблицы, поймёте ли, откуда берётся идентификатор, и подумаете ли о том, как убрать за собой созданную запись.

Как отвечать

Начните с вопроса про DDL: какие поля обязательны, у каких есть значение по умолчанию, есть ли внешние ключи и уникальные индексы. Затем пишите так, чтобы идентификатор отдавала база:

INSERT INTO location (name, latitude, longitude, created_at)
VALUES ('Тестовая точка', 55.75, 37.62, now())
RETURNING id;

Объясните два решения. Колонка идентификатора не перечислена, потому что она автоинкрементная: ручная вставка значения не двигает последовательность, и очередная вставка приложения потом упадёт на дубле ключа. RETURNING в PostgreSQL сразу отдаёт созданный идентификатор, его можно использовать в следующем шаге проверки, не делая отдельный SELECT.

Добавьте то, что ждут именно от QA. Вставку подтверждают чтением. Повторный запуск не должен ломать прогон, поэтому пригодится ON CONFLICT DO NOTHING или уникальный суффикс в имени. Сама запись создаётся в транзакции с откатом либо удаляется в завершающем шаге, чтобы стенд оставался чистым.

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

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

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

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