Playwright CI setup
Мінімальна послідовність для browser tests у CI: checkout, Python/dependency setup, встановлення browser dependencies, запуск pytest і збереження diagnostic artifact.
2. Практика та написання пайплану CI/CD →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Setting up CI
Показує first-party end-to-end CI sequence для checkout, Python, dependencies, browsers, pytest і trace artifact.
2. Практика та написання пайплану CI/CD → Першоджерело ↗Мінімальний CI setup для Chromium
Команди відокремлюють Python dependencies, сумісний Chromium із системними бібліотеками та сам test run.
CI runner має потрібний Chromium і запускає pytest suite.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →Continuous Integration | Playwright Python
Дає актуальний contract CI: package, browser/system dependencies, запуск tests.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки → Першоджерело ↗Environment variables мають вищий пріоритет
Оскільки load_dotenv() не override-ить наявні environment variables за замовчуванням, CI або shell може без зміни .env надати іншу конфігурацію.
system dependencies
ОС-бібліотеки, потрібні браузеру в CI. Playwright CLI може встановити їх разом із browser binary через --with-deps.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →Поведінка тестів у CI
Багато CI-систем встановлюють стандартну environment variable `CI`. Проєкт читає її, щоб увімкнути CI-специфічні налаштування: headless browser, відсутність локального video recording або іншу політику traces. Це дозволяє зберегти один кодовий шлях із мінімальною конфігураційною різницею. Зміни комітяться й пушаться в task branch, після чого результат перевіряється не лише за загальним статусом, а й за logs конкретної job.
Одна схема ключів, CI secrets і `.env.example`
Код має звертатися до стабільних логічних ключів на кшталт `BASE_URL`, не до `DEV_BASE_URL` або `STAGE_BASE_URL` з ручним replace. Цільове середовище вибирає джерело значень, а не інші назви змінних. Завдяки цьому локальний і CI-запуск проходять тим самим шляхом. У CI значення зберігаються як захищені secrets/variables або як секретний файл. Репозиторій містить лише `.env.example` чи аналогічний шаблон зі структурою та без реальних credentials. Якщо використовується config server, CI може зберігати лише мінімальні credentials для доступу до нього.
Діагностика hover-різниці на CI
Trace показує реальну причину: на CI hover відбувся, але очікуваний UI state не став видимим так, як локально. Це звужує проблему з абстрактного «тест падає на CI» до конкретної взаємодії браузера й locator assertion. У демонстрації перевірка адаптується для CI/headless режиму, а також розглядається примусова взаємодія. Такий workaround треба застосовувати лише після перегляду trace: інакше легко приховати реальний дефект сторінки або тесту.
Навіщо тестам явна конфігурація
Однакова конфігурація потрібна, щоб локальний запуск і CI поводилися передбачувано. У проєкті фіксуються мінімальні версії `pytest`, `pytest-playwright`, `pytest-html`, Faker та інших залежностей. Це дає IDE, pytest і CI явні передумови замість неявної залежності від локального середовища автора. На початку також показано Local History і Smart Checkout у PyCharm/IntelliJ. Ці інструменти можуть допомогти повернути локальні зміни або розібрати конфлікт під час перемикання гілки, але не замінюють Git-історію та перевірку diff.
Pipeline, stage, job і YAML
Для запуску Python-тестів у CI потрібно відтворити ті самі базові дії, що й локально: отримати код, встановити Python і залежності, окремо встановити браузери Playwright, запустити lint/format checks та потрібний набір тестів. `pipeline` описує весь процес, а `stage`, `job` і `step` — його менші етапи; точна вкладеність і назви залежать від GitHub Actions, GitLab CI, Jenkins, TeamCity, Bamboo чи іншої системи. Найпоширеніший декларативний формат — YAML. Він дає змогу зберігати pipeline поруч із кодом і однаково описувати послідовність команд, образ середовища, залежності між jobs та умови запуску без окремої мови програмування для кожного CI-продукту.
Та сама підготовка потрібна в CI
У CI перед тестами теж потрібен крок встановлення браузерів. Підготовка runner має відтворювати локальні передумови явно; наявність залежності у `requirements.txt` не замінює цього кроку. Практично варто встановлювати лише ті браузери, які справді запускає pipeline. Це скорочує час і обсяг завантаження без нового шару конфігурації.
Від простого UI-тесту до Page Objects, API та CI
[Дивитися з 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.
Консольний запуск, HTML report і Git hygiene
Запуск простої команди `pytest` у терміналі відтворює спосіб, у який suite згодом стартуватиме на CI. Така перевірка важлива: запуск через IDE може мати інший working directory, environment або власні параметри. `pytest-html` створює початковий звіт зі статусами тестів і доступними логами. Його достатньо для першої діагностики на CI: знайти failed test, переглянути повідомлення, а потім локально відтворити проблему з trace. Звіт не замінює повну observability, але дає мінімальний переносний артефакт. Каталоги з HTML-звітами, screenshots і traces додаються до `.gitignore`. Це результати конкретного запуску, а не вихідний код; їх треба публікувати як CI artifacts, а не комітити в репозиторій.
Local і remote execution
Локально Selenium client, driver і browser часто знаходяться на одній машині, тому додаткові HTTP round trips майже непомітні. У remote topology команди можуть пройти від CI runner до Selenium Server/Grid, далі до remote node або cloud browser і назад. Polling explicit waits множить network latency на кількість перевірок. Географія також впливає на system behavior: CI runner, browser node і application backend у різних регіонах дають інший latency profile, ніж локальна машина. Тому green local run не доводить, що timeout достатній для Grid/BrowserStack. Remote suite треба перевірити до merge, а browser nodes за можливості розміщувати ближче до application environment. У Playwright очікування й action orchestration потребують менше client-side polling round trips, тому modern UI suite зазвичай працює швидше й стабільніше. Але запити самої сторінки до backend однаково залежать від мережі: Playwright не прибирає latency тестованої системи.
Класифікація тестів і перший pull request
Перед CI-запуском переглядаються pytest markers: частина тестів переноситься зі smoke до regression, окремо позначаються API, web і Selenium paths. Після відкриття pull request треба ще раз перевірити diff, reviewers і checks, щоб випадково не опублікувати зайві файли або credentials. Перший pipeline закономірно знаходить lint і formatting problems. Їх виправляють локально тими самими командами, що виконує CI, комітять і повторюють запуск. CI тут є відтворюваною перевіркою, а не заміною локального feedback loop.