Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Оберіть одну DTO з проєкту.
Для кожного field зафіксуйте source entity/service, mapping rule, nullability, required status, serializer behavior і regression test.
Додайте один gateway header, який має пройти до внутрішнього service.
Mapping table і один перевірений routing contract.
String key/value у process environment. У Python os.environ надає mapping цих значень, а os.getenv() повертає value або default.
Current Android guidance перелічує Espresso, UI Automator і Compose Test як окремі instrumented testing APIs. Це уточнює перелік інструментів із відео, але не встановлює універсальне mapping без аналізу конкретного UI.
Типи мобільних застосунків та мобільна автоматизація →Описати typed object з одним boundary field.
Створити валідний object у arrange.
Передати його у create action.
Звірити ті самі expected fields в API response і UI details.
Зберегти seed у failure output.
Один test відтворює data set і виявляє помилку mapping на конкретному checkpoint.
Навіть просте перейменування `surname` на `lastName` зачіпає кілька шарів: database/entity, зовнішній service, mapping і DTO. Якщо API має повертати `fullName`, service може формувати його з `name` та `lastName`; отже, механічне копіювання одного поля дасть синтаксично валідний, але семантично неправильний response. Що більше полів і mapping rules, то вищий ризик пропустити зв’язок або зберегти не те значення. Тести мають перевіряти не лише наявність response, а й коректність значень після всіх перетворень.
Одна сутність може мапитися різними backend endpoints, DTO та frontend components. Старий copy-paste або неповний refactoring часто дає `undefined`, різне форматування чи пропущене поле лише на проміжній сторінці. Автоматизація може дешево перевірити expected data після створення, у списку, деталях, recently viewed та після update, а не лише в кінцевій точці сценарію.
На спрощеній схемі є database table із полями користувача, entity для роботи з нею, service із бізнес-логікою та mapping, controller з endpoints і DTO, яке повертається клієнту. Response не обов’язково є прямою копією одного рядка: service може звертатися до іншої таблиці або зовнішньої системи, наприклад по `taxId` чи додаткові атрибути. Поля на кшталт `createdAt`, `updatedAt` і `deletedAt` можуть зберігатися в базі, але не віддаватися назовні безпосередньо. DTO формує публічний контракт, а service відповідає за перетворення внутрішніх даних у цей контракт.
Якщо застосунок використовує зрілий framework і ORM, automation suite не має доводити, що framework у принципі вміє зберігати рядок. Цінність дають перевірки власної конфігурації: migrations, column types, precision, foreign keys, transaction boundaries, custom queries і mapping між database та API. Часто API або UI test уже опосередковано проходить database integration. Окремий DB assertion потрібен, коли зовнішня відповідь не доводить важливу властивість persistence — наприклад audit record, точність money value або асинхронний статус. Для dashboards, statistics і Big Data ключовою є не сама таблиця, а правильність агрегації: joins, filters, rounding, time zones і перетворення backend. Тут доцільно порівнювати результат із контрольованим dataset або незалежно обчисленим oracle, а не дублювати той самий SQL у тесті.
Тест, який перевіряє тільки `200 OK`, пропустить відсутнє поле, `null`, порожній рядок або неправильний mapping. Навіть перевірка переліку полів не гарантує правильного типу чи змісту. Deserialization і schema validation дають дешевий базовий захист: response приводиться до строгої моделі, тому тест одразу виявляє відсутнє поле або неправильний тип. Для цього згадуються інструменти на кшталт Zod у TypeScript і Pydantic у Python. Окремо треба врахувати serializer settings: backend може зовсім вилучати з JSON поля зі значенням `null`.
У GraphQL client зазвичай звертається до одного endpoint і в request описує потрібні fields та зв’язки. Queries читають дані, mutations змінюють їх. Якщо екрану потрібні user і всі його pets, GraphQL layer сам визначає, які downstream services викликати і як звести результат. Для тесів важливо знати цей internal mapping. Тоді покриття можна розділити за downstream service і полем, а при падінні однієї частини очікувати точний набір failures, а не безадресне падіння всіх API-тесів.
Окремий resource test детально перевіряє schema, типи та mapping конкретної сутності. Business-flow test фокусується на ключових результатах і досяжності сценарію, не дублюючи кожну дрібну assertion з ресурсного рівня. Частину детальних перевірок можна перенести на component/integration level, але лише якщо команда знає, що потрібний контракт там справді покритий і цим evidence можна довіряти. Інакше «це вже десь тестується» залишає реальну прогалину.
Під час міграції можна правильно перенести 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.
Proxyman, Charles або Fiddler дозволяють перехопити request, змінити його, затримати відповідь чи підмінити response. Так перевіряються offline mode, повільний інтернет, перемикання Wi-Fi/LTE, timeouts, `4xx`/`5xx` і неочікувані backend payloads. Особливу увагу приділено `null`, відсутнім полям і зміні типів: замість масиву може прийти `null`, число може мати інший тип, а object mapping — завершитися crash. Mobile client має коректно переживати serialization/deserialization помилки й недоступність third-party services.