Міграція бази даних і тестування даних

Питання учасника: якщо POST повернув 200 OK із порожнім body, чи достатньо цього для перевірки створення сутності. В event-driven архітектурі успішна відповідь може означати лише прийняття команди, а фактичний запис з’явиться пізніше, тому наступний GET перевіряє спостережуваний результат.

Лектор розділяє два типи coverage: сценарій для конкретного ресурсу та повний business flow. CRUD/resource test локалізує помилку в операціях над сутністю; сценарний тест перевіряє, що ланцюжок бізнес-дій працює цілісно. Один тип не замінює інший, бо дефект може проявитися лише на конкретному стику.

На спрощеній схемі є database table із полями користувача, entity для роботи з нею, service із бізнес-логікою та mapping, controller з endpoints і DTO, яке повертається клієнту. Response не обов’язково є прямою копією одного рядка: service може звертатися до іншої таблиці або зовнішньої системи, наприклад по taxId чи додаткові атрибути.

Поля на кшталт createdAt, updatedAt і deletedAt можуть зберігатися в базі, але не віддаватися назовні безпосередньо. DTO формує публічний контракт, а service відповідає за перетворення внутрішніх даних у цей контракт.

Навіть просте перейменування surname на lastName зачіпає кілька шарів: database/entity, зовнішній service, mapping і DTO. Якщо API має повертати fullName, service може формувати його з name та lastName; отже, механічне копіювання одного поля дасть синтаксично валідний, але семантично неправильний response.

Що більше полів і mapping rules, то вищий ризик пропустити зв’язок або зберегти не те значення. Тести мають перевіряти не лише наявність response, а й коректність значень після всіх перетворень.

Під час декомпозиції логіку, яка раніше жила в одному або кількох класах, переносять у різні services. Треба не лише перенести записи, а й зберегти правила зіставлення полів та джерела кожного значення.

Показано типовий регресійний ланцюжок: fullName випадково мапиться лише з lastName; локальний fix додає name, але дані все одно не оновлюються, бо справжнім джерелом був інший service. Так само похідний status може формуватися з timestamps лише на одному code path і залишитися null під час читання.

Тест, який перевіряє тільки 200 OK, пропустить відсутнє поле, null, порожній рядок або неправильний mapping. Навіть перевірка переліку полів не гарантує правильного типу чи змісту.

Deserialization і schema validation дають дешевий базовий захист: response приводиться до строгої моделі, тому тест одразу виявляє відсутнє поле або неправильний тип. Для цього згадуються інструменти на кшталт Zod у TypeScript і Pydantic у Python. Окремо треба врахувати serializer settings: backend може зовсім вилучати з JSON поля зі значенням null.

from pydantic import BaseModel, ConfigDict, ValidationError

class UserDto(BaseModel):
    model_config = ConfigDict(strict=True, extra="forbid")
    id: int
    fullName: str
    status: str

valid = UserDto.model_validate({"id": 42, "fullName": "Ada Lovelace", "status": "active"})
assert valid.id == 42

for invalid in (
    {"id": "42", "fullName": "Ada Lovelace", "status": "active"},
    {"id": 42, "fullName": "Ada Lovelace"},
):
    try:
        UserDto.model_validate(invalid)
    except ValidationError:
        pass
    else:
        raise AssertionError(f"payload accepted unexpectedly: {invalid}")

Для критичних контрактів рекомендовано схилятися до strict validation: обов’язкове поле має бути присутнім і мати визначений тип. Щоб така перевірка була змістовною, test fixture треба створювати з повним набором даних, а не випадково залишати половину полів порожніми.

Генерація готових моделей прискорює роботу, але ручний red/green шлях іноді знаходить backend defects саме під час поступового заповнення й перевірки полів. Повністю «ідеальна» згенерована модель може приховати досвід негативних сценаріїв, хоча саме неочікувані дані часто відкривають проблеми.

Окремий resource test детально перевіряє schema, типи та mapping конкретної сутності. Business-flow test фокусується на ключових результатах і досяжності сценарію, не дублюючи кожну дрібну assertion з ресурсного рівня.

Частину детальних перевірок можна перенести на component/integration level, але лише якщо команда знає, що потрібний контракт там справді покритий і цим evidence можна довіряти. Інакше «це вже десь тестується» залишає реальну прогалину.

Клієнт звертається до одного зовнішнього API gateway, хоча за ним працюють окремі user/account та appointment services. Gateway перетворює зовнішній route і проксіює request у внутрішню мережу до відповідного service; зовнішнє й внутрішнє найменування ресурсу може відрізнятися.

Service, у свою чергу, може читати кілька tables, звертатися до інших services, виконувати filters і mappings, а controller повертає сформовану DTO. Тому response одного endpoint залежить не від одного методу, а від усього ланцюжка.

Під час міграції можна правильно перенести service, але помилитися в gateway route: не прокинути authorization header, body або інший обов’язковий параметр. Клієнт передасть credentials, gateway прийме request, а внутрішній service поверне 401, бо потрібний header загубився між ними.

API tests швидко виявляють такі дефекти mapping, schema й routing без довгого пошуку причини через UI. Практична стратегія сесії: окремо перевіряти контракт ресурсу, окремо — ключові business flows, а під час database чи infrastructure migration запускати обидва набори як regression coverage.