Відеобібліотека
Пошук у нотатках курсу Design Patterns для автоматизаторів з переходом на потрібну секунду.
Request і response радять представляти типізованими objects, а не збирати JSON-рядки вручну. DTO групує поля suite, user чи report і дозволяє controller приймати один аргумент замість довгої сигнатури. На ранньому етапі можна тимчасово витягнути одне поле через JSONPath, якщо повна model ще не потрібна. Коли перевірки розширюються до всього response, цей seam замінюється DTO без зміни business flow тесту.
Response wrapper/decorator може централізовано перевіряти status code, витягувати body та формувати зрозуміле failure message. Коли однакові checks дублюються між controllers, вони переносяться у resource-specific assertion class, наприклад assertions для suite response. Generated API clients часто кидають exceptions на `4xx/5xx`, через що negative tests змушені розбирати exception body і status. Окрема assertion layer може бути простішою. AssertJ-style generated assertions і обов'язкові пояснення `because` покращують grouping однакових failures у report.
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.
Перший API-test може напряму сформувати URL, headers, credentials, body та перевірити status code. Але десятки низькорівневих рядків приховують намір на кшталт “authorize user” або “create suite”. Окрім документації HTTP client library, автор радить дивитися її unit/integration tests: там є реальні приклади form parameters, headers, POST body та response handling. Після Proof of Concept повторюваний protocol code ховається за доменними методами.
Встановлена mobile app продовжує використовувати відому їй версію API, навіть коли backend уже оновлено. Несумісна зміна поля або структури response може масово зламати старі iOS/Android builds, тому новий контракт виносять у `v2`, не руйнуючи `v1`. Перевіряти потрібно обидва напрямки сумісності: стару app з новим backend і нову app зі старішим доступним backend contract. Це особливо важливо для користувачів, які рідко оновлюють застосунок.
`v1`, `v2` і наступні versions дозволяють підтримувати mobile clients та third-party integrations, які залежать від старого response shape. Tests для обох контрактів краще розділити явно, а не наповнювати один controller умовами. OpenAPI/Swagger schema може згенерувати request/response models і clients для Java, C#, Python або TypeScript. Це економить ручне створення DTO, але generated code потрібно перевірити: його default exception handling не завжди зручний для negative API assertions.
Hibernate або Entity Framework можуть mapити database rows у `UserEntity`, `SuiteEntity` та інші types. Models можна повторно використати через спільну library або підтримувати окремо в test project, якщо прямої залежності від application code немає. Backend flow часто проходить repository/DAO → entity → DTO → controller response. Розуміння цих перетворень допомагає локалізувати mismatch між database state й API JSON, але automation-код не повинен відтворювати всю production реалізацію.
У TypeScript-прикладі factory method створює registration DTO з random data, Controller приймає DTO, Axios config зберігає базові settings, а response decorator порівнює фактичний JSON з типізованою model. Якщо поле відсутнє, custom error підказує class і type, які потрібно оновити. Для продукту з різними clients, roles і permissions UI-перевірки краще групувати невеликими components або role-specific classes. Менші класи полегшують code review і зменшують merge conflicts, але надмірне дроблення так само небажане; shared page behavior залишається спільним.