Ответ
В тестировании проверка на отсутствие дубликатов — это валидация бизнес-логики или корректности запроса к БД. Я подхожу к этому с двух сторон: проверка API/логики приложения и прямая проверка данных в БД.
1. Проверка на уровне API/приложения: Если endpoint, например, возвращает список пользователей, я проверяю, что в ответе нет повторяющихся ID или других уникальных комбинаций полей.
Пример автотеста на Python (pytest):
import requests
def test_user_list_has_no_duplicates(api_base_url):
"""Проверяем, что GET /users не возвращает дубликатов по id."""
response = requests.get(f"{api_base_url}/users")
response.raise_for_status()
users = response.json()
# Извлекаем все id
user_ids = [user['id'] for user in users]
# Преобразуем в set (убирает дубликаты) и сравниваем длину с исходным списком
unique_ids = set(user_ids)
assert len(user_ids) == len(unique_ids),
f"Найдены дубликаты пользователей. ID дубликатов: {[id for id in user_ids if user_ids.count(id) > 1]}"
2. Проверка на уровне базы данных (SQL):
Чаще всего дубликаты возникают из-за ошибки в запросе (JOIN без корректного условия) или из-за некорректных данных в самой БД.
-
Поиск дубликатов в результатах запроса: Можно использовать
GROUP BYиHAVING COUNT(*) > 1.-- Найти email, которые встречаются больше одного раза в таблице users SELECT email, COUNT(*) as count FROM users GROUP BY email HAVING COUNT(*) > 1; -
Проверка уникальности на уровне схемы БД: В идеале, поля, которые должны быть уникальными (логин, email), должны иметь ограничение
UNIQUE CONSTRAINT. В тестах можно проверить, что попытка вставить дубликат вызывает ожидаемую ошибку.
3. В контексте тест-дизайна: При тестировании функций создания/добавления данных я обязательно включаю кейс 'Попытка создать дублирующую запись' (например, зарегистрировать пользователя с уже существующим email) и проверяю, что система возвращает адекватную ошибку, а не создает дубль.