1. Налаштування Playwright та Pytest, простий репортінг

Однакова конфігурація потрібна, щоб локальний запуск і CI поводилися передбачувано. У проєкті фіксуються мінімальні версії pytest, pytest-playwright, pytest-html, Faker та інших залежностей. Це дає IDE, pytest і CI явні передумови замість неявної залежності від локального середовища автора.

На початку також показано Local History і Smart Checkout у PyCharm/IntelliJ. Ці інструменти можуть допомогти повернути локальні зміни або розібрати конфлікт під час перемикання гілки, але не замінюють Git-історію та перевірку diff.

У pytest.ini задаються каталоги з тестами, шаблони імен тестових файлів і функцій та директорії, які не потрібно сканувати. Це звужує test discovery до структури проєкту й прибирає зайву роботу з .git, .idea, build-артефактами та кешами.

Через addopts виносяться параметри, які мають застосовуватися до кожного запуску: verbose output, короткий traceback, відображення output лише для failed tests, strict markers, Playwright tracing і генерація self-contained HTML report. Маркери smoke, regression, web та slow реєструються явно, щоб помилка в назві не перетворилася на тихе пропускання потрібної групи.

Для traces обирається retain-on-failure: артефакт створюється під час тесту, але зберігається лише після падіння. Це практичніший default, ніж trace для кожного успішного тесту, бо архіви можуть швидко зайняти багато місця.

[pytest]
testpaths = .
addopts = -q --strict-markers
markers =
    smoke: critical product flow

Запуск простої команди pytest у терміналі відтворює спосіб, у який suite згодом стартуватиме на CI. Така перевірка важлива: запуск через IDE може мати інший working directory, environment або власні параметри.

pytest-html створює початковий звіт зі статусами тестів і доступними логами. Його достатньо для першої діагностики на CI: знайти failed test, переглянути повідомлення, а потім локально відтворити проблему з trace. Звіт не замінює повну observability, але дає мінімальний переносний артефакт.

Каталоги з HTML-звітами, screenshots і traces додаються до .gitignore. Це результати конкретного запуску, а не вихідний код; їх треба публікувати як CI artifacts, а не комітити в репозиторій.

Playwright дозволяє передати частину параметрів через CLI, але для керованої конфігурації у відео перевизначаються pytest fixtures browser_type_launch_args і browser_context_args. Перша група відповідає за запуск браузера: headless, slow_mo, launch timeout і browser channel. Друга — за ізольований browser context: viewport, locale, timezone, permissions, HTTPS errors, headers, base URL та запис відео.

Viewport варто обирати з підтримуваних продуктом меж. Мінімальний підтримуваний розмір часто краще виявляє перекриття й недоступні елементи, ніж великий екран розробника. При цьому viewport — це область сторінки всередині браузера, а не повний розмір системного вікна.

slow_mo корисний для демонстрації або візуальної діагностики, але не є способом синхронізації й не повинен маскувати flaky tests. Надійний тест очікує конкретний стан через locator assertions або іншу умову, а не покладається на постійну затримку між діями.

У спрощеній моделі Playwright спочатку запускає browser process, потім створює ізольований BrowserContext, а в ньому — одну або кілька Page. Launch options стосуються процесу браузера, context options — сесії користувача, cookies, permissions та емуляції, а Page представляє вкладку й виконує дії зі сторінкою.

Через channel="chrome" можна запустити встановлений branded Chrome замість bundled Chromium. Це потрібно, коли поведінка залежить від повного браузера або медіакодеків; для більшості перевірок швидшого bundled Chromium достатньо.

Маркери дають змогу виконувати smoke і regression окремо. Практичний CI flow: спочатку короткий smoke suite перевіряє, що середовище придатне до тестування, і лише після нього запускається довша regression suite.

Для демонстрації навмисно ламається locator, після чого збережений trace.zip відкривається командою playwright show-trace <path>. Trace Viewer показує послідовність actions, стан сторінки до й після кожної дії, source line, console errors і network requests.

Timeline допомагає побачити не лише місце падіння, а й час очікування. Виділивши потрібний інтервал, можна звузити network-події до конкретної дії. Snapshot сторінки також дозволяє перевірити DOM і locator навіть тоді, коли браузер із failed run уже закритий — наприклад, помітити завислий loader або overlay.

page.pause() зупиняє виконання й відкриває Playwright Inspector. У ньому можна покроково продовжувати тест, підсвічувати елементи, досліджувати locators і записувати дії. У відео для швидкої вставки pause створюється IDE Live Template.

Альтернатива — звичайний breakpoint і Debug у PyCharm. Step over, Step into My Code і Step out дають контроль над Python-викликами, а Evaluate Expression дозволяє перевіряти locator або інший вираз у поточному стані. Playwright Inspector зручніший для браузерної частини, debugger IDE — для Python state; обирати варто за місцем проблеми.

Failed output можна передати LLM у контексті проєкту, щоб скоротити час на читання великого traceback або логів. Найкраще це працює в IDE-інструменті, який бачить код і пов'язані файли. Водночас демонстрація показує межу підходу: модель може змінити порядок дій або запропонувати неправильний fix, тому її diff і повторний запуск тесту завжди треба перевіряти.

Практика після уроку — перенести параметри браузера й context у fixtures, спробувати headless/headed режими, viewport, timeout і slow_mo, навмисно зламати тест та пройти повний цикл діагностики через HTML report, trace і debugger.