Page Object Model
Організаційний підхід, у якому page-specific structure і services інкапсулюються в об’єкті сторінки, зменшуючи дублювання та локалізуючи зміни UI.
2. Selenium організація PageObject's та Очікувань →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Авторські приклади API client і Page Object
Pinned приклад пов’язує API client і Page Object із переходом уроку від прямого UI-flow до reusable automation structure. Код не скопійовано через відсутність LICENSE у repository.
Практика курсу на YOY, домашні завдання та формат ПМП → Першоджерело ↗uv project structure and lockfile
Підтверджує й актуалізує поняття уроку, пов’язані з uv.lock.
1. Фіксаємо назви файлів, рефакторинг та оптимізація під Python, підключаємо Ruff та uv → Першоджерело ↗uv project structure and lockfile
Підтверджує research-уточнення цього уроку.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів → Першоджерело ↗Спроєктувати V0 structure без speculative folders
Візьміть один реальний web або API automation scope.
Створіть лише folders, які мають хоча б один поточний consumer.
Запишіть measurable condition для винесення database, messaging або другого domain на окремий рівень.
Мінімальне tree representation і три explicit upgrade conditions.
Структура `src` і Python package
Для експериментів створюється `src` і окремий Python package. У класичному package файл `__init__.py` явно позначає директорію як пакет для інструментів і імпортів. Сучасний Python також підтримує namespace packages без `__init__.py`, але явний пакет часто передбачуваніший для навчального проєкту. Експерименти з типами відокремлюються від тестів: короткий файл можна запускати напряму, щоб перевірити перетворення або метод перед вбудовуванням у сценарій.
Структура папок і створення проєкту
Перед створенням проєкту варто перевірити його фізичний шлях. Особисті та робочі репозиторії краще розділяти: наприклад, тримати open-source й особисті проєкти в окремій папці, а робочі — у папці конкретної компанії. Це зменшує плутанину між різними обліковими записами, репозиторіями та середовищами. Навчальний проєкт присвячений Testomat.io — системі керування тестами. У ньому далі автоматизуватимуться операції зі створення проєктів, папок і тест-кейсів. Під час створення можна залишити стартовий скрипт. Нові файли проєкту варто додавати до Git, якщо вони справді є частиною коду; зайве згодом можна видалити або додати до `.gitignore`.
Розділення `conftest.py` через pytest plugins
Один `conftest.py` накопичив конфігурацію, запуск браузера, створення сторінки й app-specific fixtures. Код розділяється на модулі `config`, `playwright` та `app`, а кореневий `conftest.py` лише підключає їх через `pytest_plugins`. Технічний шар створює браузер і context; app-шар виконує login, перевіряє, що цільова сторінка завантажена, і зберігає state. Такий поділ залишає місце для Firefox або інших browser options без змішування з бізнесовими переходами.
MVC як структура API-тестів
Показано спрощене застосування Model–View–Controller. `Model` описує DTO і response data; `Controller` інкапсулює запити; роль view у цьому тестовому контексті не розвивається. Кожен REST resource — projects, suites, runs, templates, tests, users — отримує власний controller з потрібними операціями `create`, `get`, `update`, `delete`. Це тримає тестовий сценарій на рівні предметних дій, а URL, headers і розбір response залишаються в одному місці.
Структура automation-проєкту росте ітеративно
Початкова структура може бути простою: спільний config, `web` із pages/components, `api` із clients/controllers та DTO, а за потреби — робота з database. Не треба заздалегідь будувати повну enterprise-ієрархію. Коли database-код розростається, його можна винести на окремий рівень і розділити на entities та repositories/DAO. Це наступна ітерація після появи кількох tables і повторюваних CRUD operations, а не стартова вимога для першого test suite.
Типізація, Arrange–Act–Assert і підсумок
Helper-функції типізуються, щоб зменшити ризик передати несумісне значення. Після рефакторингу набір містить сценарії невалідного логіну, успішної авторизації з пошуком і перемикання категорії проєктів. Наприкінці вводиться структура Arrange–Act–Assert: підготувати дані й передумови, виконати дію, перевірити результат. Arrange може згодом переїхати у fixture, але на цьому етапі важливіше явно бачити три ролі коду. Практика після відео — додати кілька сценаріїв і виносити helper-функції лише там, де вони справді покращують читання або прибирають повторення.