OpenAPI Specification v3.1.0
Дає формальний contract для schema, types і required properties API payload.
Міграція бази даних і тестування даних → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Erased types
TypeScript type annotations використовуються під час static checking, але стираються з emitted JavaScript і не змінюють runtime behavior.
Який рівень програмування потрібен automation engineer →OOP, патерни й ізоляція browser state
На базовому рівні потрібно розуміти primitives/value types, reference/object types, класи, об'єкти та принципи OOP. Із прикладних патернів найчастіше зустрічається Page Object; корисно впізнавати Singleton, Builder, Facade та інші рішення, але не впроваджувати їх без проблеми, яку вони реально спрощують. Page Factory виник навколо старих Selenium-підходів із lazy initialization елементів. Для сучасного Selenium або Playwright його не варто застосовувати за інерцією. У багатопоточному WebDriver framework кожен тест/worker повинен мати власний browser context або driver; спільний mutable driver спричиняє взаємний вплив тестів.
OpenAPI, JSON types і шлях даних
Автор розбирає Swagger/OpenAPI descriptions і JSON як мову обміну між clients та backend. Тип, format, required fields, arrays і dates важливі не менше за business value. Окрема тема — перетворення дат і numbers між database, backend і frontend. Якісний test design залежить від розуміння цих transformations; black-box response assertion може не показати, на якому рівні виник defect.
Типізовані дані як наскрізний контракт
Між functions передають типізовані `UserDto`, `ProductDetails`, `CompanyDetails` або інші domain types замість розрізнених primitive values. Це робить required fields видимими, спрощує повторні assertions і зменшує ризик переплутати дані. Конкретні приклади реалізації розгортаються далі в курсі.
Вебсервіси, SOAP і RESTful
Вебсервіс подається як software component, через який розподілені системи обмінюються даними. SOAP оперує messages і XML contracts, тоді як RESTful services будують інтерфейс навколо resources та HTTP semantics. Автор порівнює XML, JSON, binary payloads і statefulness. Практичний висновок для тестувальника: перед автоматизацією треба визначити реальний protocol, media types і contract, а не припускати REST лише за JSON payload.
Event builder як набір automation-задач
[Дивитися з 03:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=210s). Багатокрокове створення event містить text fields, images, dates, location/online/hybrid modes, speakers і publish action. Для першої ітерації достатньо послідовних Playwright operations: знайти element, заповнити, натиснути й перевірити видимий результат. Окремі tests можуть покривати різні event types та їх відображення після публікації.
Глибина знань зростає разом із seniority
Для middle і особливо senior рівня очікується розуміння типів даних, проходу collections, роботи з files та databases, object lifecycle, scope variables, initialization order і test runner lifecycle. Ці знання зазвичай закріплюються після реальної проблеми, а не після ізольованої лекції. Тому відповідь не вимірюється списком syntax topics. Junior має безпечно змінювати прості scripts; middle — діагностувати non-obvious behavior; senior — пояснювати system-level root cause й обирати правильний test seam.
Що перевіряти замість повторного тестування СУБД
Якщо застосунок використовує зрілий 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 у тесті.
Assertions у тесті і перехід до DTO
Первинні перевірки мають бути видимими в тесті, а не захованими в controller. Тому API method повертає `Response`, а test явно перевіряє status code. Така структура спрощує code review і показує, що саме доводить сценарій. Наступний крок — замінити JSON strings на data transfer objects, щоб мати Java types, autocomplete і зручне оновлення полів. Додаються Java Faker для унікальних test data і Lombok для генерації boilerplate. Для Lombok у IntelliJ IDEA потрібні plugin і ввімкнений annotation processing.
`RequestSpecification`, authorization і content negotiation
`RequestSpecification` зберігає спільні налаштування request: `baseUri`, `basePath`, logging та інші параметри. Окремі specifications можуть описувати різні domains або request types, наприклад multipart. У тесті синтаксичні `when` і `then` можна опусти, якщо після HTTP method одразу обробляється `Response`. Token передається в authorization header. У RestAssured є спеціалізовані auth methods, але в прикладі header задається явно. `Content-Type` описує формат request body, `Accept` — бажаний формат response. Неправильний або відсутній header може дати `4xx`, тому потрібний набір перевіряється експериментально.
Чому перевірки лише status code недостатньо
Тест, який перевіряє тільки `200 OK`, пропустить відсутнє поле, `null`, порожній рядок або неправильний mapping. Навіть перевірка переліку полів не гарантує правильного типу чи змісту. Deserialization і schema validation дають дешевий базовий захист: response приводиться до строгої моделі, тому тест одразу виявляє відсутнє поле або неправильний тип. Для цього згадуються інструменти на кшталт Zod у TypeScript і Pydantic у Python. Окремо треба врахувати serializer settings: backend може зовсім вилучати з JSON поля зі значенням `null`.