Built-in Types
Підтверджує й актуалізує поняття уроку: Text Sequence Type — str / Mutable Sequence Types.
4. Типізація даних (str, int, float, bool) → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Allure Pytest reference
Фіксує API steps, attachments, media types і pytest-specific metadata.
4. Allure репорт, основи та інтеграція в CI → Першоджерело ↗Attachments
Фіксує API та media types для screenshots і інших diagnostic files.
4. Allure репорт, основи та інтеграція в CI → Першоджерело ↗OpenAPI Specification v3.1.0
Дає формальний contract для schema, types і required properties API payload.
Міграція бази даних і тестування даних → Першоджерело ↗Pydantic validation не завжди є strict
Current Pydantic v2 documentation states that input may be converted to declared types and extra fields are ignored by default. Якщо API-тест має виявляти будь-який schema drift, strict behavior і extra='forbid' треба задати явно.
Не встановлено: точну Pydantic version у відео не названо.
2. API автоматизація одразу правильно, MVC, pydantic →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 спричиняє взаємний вплив тестів.
Типізовані дані як наскрізний контракт
Між functions передають типізовані `UserDto`, `ProductDetails`, `CompanyDetails` або інші domain types замість розрізнених primitive values. Це робить required fields видимими, спрощує повторні assertions і зменшує ризик переплутати дані. Конкретні приклади реалізації розгортаються далі в курсі.
`str`, `int`, `float`, `bool` і запуск прикладів
Змінна отримує тип із присвоєного значення: текст у лапках стає `str`, ціле число — `int`, число з десятковою крапкою — `float`, а `True`/`False` — `bool`. `type(value)` допомагає побачити фактичний тип. Файл можна запускати кнопкою Run в IDE й одразу звіряти оголошені значення з console output.
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 у тесті.
Чому перевірки лише status code недостатньо
Тест, який перевіряє тільки `200 OK`, пропустить відсутнє поле, `null`, порожній рядок або неправильний mapping. Навіть перевірка переліку полів не гарантує правильного типу чи змісту. Deserialization і schema validation дають дешевий базовий захист: response приводиться до строгої моделі, тому тест одразу виявляє відсутнє поле або неправильний тип. Для цього згадуються інструменти на кшталт Zod у TypeScript і Pydantic у Python. Окремо треба врахувати serializer settings: backend може зовсім вилучати з JSON поля зі значенням `null`.
REST і GraphQL уже дають словник для API automation
У REST структура починається з resources та HTTP methods. `Pet`, `Store` або `User` задають назви controllers/clients, а дії на кшталт create, update, delete чи find by ID — назви методів. Request і response models корисно розділяти, бо server response часто містить поля, яких не було у request. У GraphQL треба повторювати назви queries, mutations, inputs і types зі schema. Code generation може дати готові типи, але базове правило те саме: не створювати паралельний словник там, де backend contract уже має точні терміни. Read-only доступ до frontend і backend repositories допомагає швидше зрозуміти систему й підтримувати automation разом зі змінами продукту.