Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Integer capability level у Python DB-API module. Значення окремо визначає, чи threads можуть share module, connections і cursors; DB-API compatibility сама по собі не гарантує безпечний shared connection.
Автомтизація баз даних та що з тим робити та що знати →Знайдіть одну OpenAPI operation за operationId.
Напишіть окремий API contract test для status і мінімальної response schema.
Передайте отриманий ID у page object і приберіть лише зайві UI setup-кроки.
API test окремо перевіряє контракт, а UI test починається з готового server-side state й перевіряє свій основний сценарій.
Створити suite у target project через SuiteController.
Отримати створену сутність через API і провалідувати response Pydantic-моделлю.
Повторити цей flow для test case через TestController.
Два API-тести проходять без UI-кроків і виявляють schema mismatch.
Поточна rendered reference показує login flow і endpoint отримання проєктів; exact authentication header слід перевіряти за чинною документацією та реальною відповіддю API.
3. API preconditions →Pinned приклад пов’язує API client і Page Object із переходом уроку від прямого UI-flow до reusable automation structure. Код не скопійовано через відсутність LICENSE у repository.
Практика курсу на YOY, домашні завдання та формат ПМП → Першоджерело ↗Показує sync API, injected page fixture, navigation і web-first assertion без залежності від мінливого повного title.
pytest знаходить один test і він проходить у Chromium.
2. Перший автотест на Python з Playwright →У курсі використовується синхронний API Playwright, щоб кроки тесту виконувалися послідовно без додаткової складності `async`/`await`. Фікстуру можна типізувати класом `Page`, а PyCharm імпортує потрібне ім’я через quick fix: ```python from playwright.sync_api import Page, expect def test_open_home_page(page: Page): ... ``` Важливо імпортувати `Page` і `expect` саме з `playwright.sync_api`, а не з асинхронного API.
UI-тест на початку наочніший: відкрити сторінку, знайти елемент, натиснути й побачити результат. Такий сценарій дає швидший практичний зворотний зв’язок людині, яка ще не звикла до IDE, коду, бібліотек і діагностики помилок. Навчальний маршрут іде від сирого сценарію до повторно використовуваних функцій і патернів проєктування, а вже потім — до оптимізації через API. Так учасник розуміє, що саме він спрощує і чому нижчий рівень може бути швидшим та стабільнішим. Postman корисний для дослідження API, але в межах цієї дискусії не вважається повноцінною заміною кодової автоматизації: складніше структурувати великі набори тестів, повторно використовувати частини сценарію й контролювати архітектуру. Для системного навчання автор обирає код та IDE.
Middle має володіти мовою настільки, щоб писати й підтримувати UI та API tests, а також пояснити, як перевірити нову поведінку й які наявні тести варто змінити. UI automation легше показує зв'язок із діями користувача, тоді як API automation часто швидша й стабільніша, але вимагає впевнено працювати з більшими структурами даних і контрактами. Очікується знання базових типів, перетворень і наслідків звуження/розширення типів, dependency/build tool свого stack (`requirements.txt`, `pip`/`uv`, Maven/Gradle, npm), а також можливостей test runner. Важливо вміти запустити тести паралельно й розуміти, які ресурси та змінні створюються для кожного worker.
[Дивитися з 00:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=0s). Playwright складається з багатьох частин: browser lifecycle, locators, actions, assertions, downloads, reporting і tracing. Щоб відповісти на питання «що відбувається під капотом», автор відкриває реалізацію `Locator`, а не обмежується документацією верхнього рівня. `Locator` зберігає frame і спосіб пошуку елемента, а додаткові умови на кшталт `has`, `hasText` чи visibility-related filters добудовують запит. У Python named arguments роблять таку композицію схожою на Builder без окремого builder class. Практичний висновок: перед створенням власного selector DSL варто перевірити вже наявні аргументи конструктора й методи locator API.
UI-сценарій має пройти довгий user journey лише для того, щоб дістатися стану, який перевіряє тест. Якщо створення або пошук проєкту не є предметом перевірки, його можна підготувати через backend API й одразу відкрити сторінку за `project_id`. Спочатку треба дослідити Network, але server-side rendering може приховати окремі XHR-запити. Тоді джерелом контракту стає офіційна OpenAPI/Swagger документація backend, а не припущення за URL інтерфейсу.
Створення або читання сутності через API проходить routing, application logic, database access і serialization, тому сотні setup-запитів накопичують час. Прямий запит до database інколи виконується за кілька мілісекунд і може бути корисним для підготовки або пошуку test data. У Java типовим низькорівневим контрактом є JDBC; у Python — драйвер конкретної СУБД, який зазвичай підтримує Python DB-API. Для підключення потрібні host/URL, database/schema, credentials і driver. Секрети не мають бути в коді, а тестовий користувач БД повинен мати мінімальні права. Прямий insert не завжди еквівалентний product operation: він може обійти validation, events, audit, caches та синхронізацію. Тому DB setup доречний лише для сутностей, де команда явно приймає такий контракт.
[Дивитися з 05:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=330s). Suite ускладнюється вертикально: спочатку прямий UI-flow, потім reusable helpers, Page Objects, розширення object model, API preconditions і повторне використання authenticated state. Складніший сценарій може створити другу людину, зареєструвати її на event і перевірити participant list від імені admin. Пізніше ті самі tests мають запускатися в CI, де з’являться окремі environment-specific failures.
У Testomat.io API token не обов’язково є готовим bearer token для всіх запитів: його може бути потрібно обміняти на JWT через login endpoint. Урок демонструє, чому тип авторизації треба перевіряти за документацією та реальною відповіддю API. Секрет зберігається в environment variable, а не в коді. Постійне використання email/password додає зайвий запит і ширший секрет; token flow варто обирати лише якщо backend справді його підтримує.
Build warnings про deprecated API — ранній сигнал, що наступна major-версія може видалити використану конструкцію. Попередження може походити не з вашого коду, а з транзитивної залежності, яка ще не адаптувалася. Перед оновленням треба встановити, які API реально використовуються та які пакети залежать один від одного. Інакше оновлення однієї бібліотеки може зламати іншу.
Для API automation потрібно окремо вивчити REST semantics: methods, resources, типові status codes і їхню очікувану поведінку. Public endpoints зазвичай оптимізовані для frontend або зовнішніх clients, private endpoints можуть обслуговувати внутрішню service-to-service communication і мати інший контракт. Самого HTTP status недостатньо. Централізований error handling має повернути consumer стабільний internal error code і зрозуміле пояснення: якого поля бракує або яке значення невалідне. Власні HTTP status codes на кшталт `600` не замінюють нормального error contract.