Ответ
Взаимодействие с БД — неотъемлемая часть проверки целостности данных и бизнес-логики.
Типичные сценарии и инструменты:
| Сценарий тестирования | Цель работы с БД | Инструменты / Методы |
|---|---|---|
| Ручное тестирование | Валидация результатов CRUD-операций, проверка связей данных. | Прямые SQL-запросы в клиенте (DBeaver, pgAdmin, psql). Пример: SELECT * FROM orders WHERE user_id = 123; |
| Автоматизированное тестирование | Подготовка тестовых данных, проверка состояния после выполнения теста. | ORM (SQLAlchemy, Hibernate), библиотеки доступа (psycopg2, JDBC). |
| Тестирование ETL/миграций | Сравнение данных до и после преобразования, проверка сложных вычислений. | Написание скриптов с множеством JOIN и агрегирующих функций. |
Пример автотеста на Python с прямой проверкой в БД:
import psycopg2
def test_order_creation(db_connection):
"""Тест проверяет, что заказ корректно сохраняется в БД."""
# 1. Действие в приложении: создание заказа через API
create_order_via_api(product_id=777, quantity=2)
# 2. Проверка в БД
cursor = db_connection.cursor()
cursor.execute("""
SELECT id, quantity, status
FROM orders
WHERE product_id = 777
ORDER BY created_at DESC
LIMIT 1
""")
db_record = cursor.fetchone()
# 3. Верификация
assert db_record is not None, "Запись о заказе не найдена в БД"
assert db_record[1] == 2 # Проверка количества
assert db_record[2] == 'pending' # Проверка статусаЧастота работы: от нескольких раз в спринт (ручные проверки) до десятков раз в день (в рамках CI/CD пайплайна с автотестами).
Ответ 18+ 🔞
Ага, ну вот, подъехали к самому сокровенному — к базе данных. Это ж, блядь, святая святых, там вся правда жизни лежит, а не то что в этих ваших логах и интерфейсах. Если приложение врет, как сивый мерин, то БД тебе честно скажет, кто тут реально накосячил.
Типичные разборки с хранилищем данных:
| Что делаем | Зачем лезем в кишки | Чем ковыряемся |
|---|---|---|
| Ручная проверка (когда надо мозги включить) | Убедиться, что после клика "Купить" деньги не испарились, а заказ прилип. | Прямо в DBeaver или psql вбиваем запрос, типа: SELECT * FROM orders WHERE user_id = 123; и смотрим, не пиздёж ли это всё. |
| Автотесты (когда надо, чтобы само всё бегало) | Нагенерить тестового дерьма, проверить состояние до и после, откатить. | Используем ORM (SQLAlchemy иже с ними) или драйверы (psycopg2), чтобы не париться с голым SQL в коде. |
| Проверка миграций и переносов (ETL) | Сравнить, что было в старой помойке и что стало в новой, после всех этих "магических" преобразований. | Пишем скрипты с кучей JOIN и агрегаций, чтобы выловить все косяки. |
Вот, смотри, как это выглядит в коде, когда тест сам лезет в базу проверить факты:
import psycopg2
def test_order_creation(db_connection):
"""Тест проверяет, что заказ не сдулся по дороге в базу."""
# 1. Симулируем действие юзера: тыкнул кнопку, отправил запрос
create_order_via_api(product_id=777, quantity=2)
# 2. А теперь лезем в базу, искать улики
cursor = db_connection.cursor()
cursor.execute("""
SELECT id, quantity, status
FROM orders
WHERE product_id = 777
ORDER BY created_at DESC
LIMIT 1
""")
db_record = cursor.fetchone()
# 3. Сверяем показания
assert db_record is not None, "Запись о заказе не найдена в БД, ёпта!"
assert db_record[1] == 2 # Количество должно совпадать, а то хуйня какая-то
assert db_record[2] == 'pending' # Статус должен быть "в ожидании", а не "уплыл"Делаем мы это с разной интенсивностью, блядь. Вручную — пару раз за спринт, когда что-то сложное ломаем. А вот автотесты в CI/CD могут эту проверку делать по десять раз на дню, чтобы сразу ловить, если кто-то криво код закоммитил.