Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Мінімальний приклад Codex на основі актуального Playwright contract: інтерактивна кнопка знаходиться за role та accessible name, а неінтерактивний текст перевіряється через get_by_text().
Після кліку на Create suite текст Select suite for test стає видимим.
Майструємо IDE під себе →Намалювати маршрут від runner до application і залежностей.
Зафіксувати потрібні credentials та мінімальні network rules.
Запустити suite з обраною concurrency й записати peak CPU/RAM.
Обґрунтувати hosted або self-hosted варіант фактичними даними.
Короткий capacity та access worksheet без універсальних припущень про RAM або вартість.
Урок конфігурує suite через pytest.ini.
Поточна документація pytest також підтримує pytest.toml, доданий у pytest 9.0. pytest.ini залишається підтримуваним і має вищий пріоритет за legacy alternatives.
pytest 9.0
1. Налаштування Playwright та Pytest, простий репортінг →Візьміть реальну browser analytics або письмову support policy продукту.
Позначте scenarios, які достатньо виконувати в Chromium/Firefox/WebKit.
Окремо позначте browser/vendor requirements, що потребують Selenium/Grid або cloud provider.
Запишіть очікувану topology, latency risks і мінімальний cross-browser suite.
Є коротке рішення Playwright-only або Playwright+Selenium, пов'язане з виміряною browser matrix, а не з популярністю інструмента.
Створити suite у target project через SuiteController.
Отримати створену сутність через API і провалідувати response Pydantic-моделлю.
Повторити цей flow для test case через TestController.
Два API-тести проходять без UI-кроків і виявляють schema mismatch.
Команди відокремлюють Python dependencies, сумісний Chromium із системними бібліотеками та сам test run.
CI runner має потрібний Chromium і запускає pytest suite.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →У прикладі suite для account management містить 12 тестів. Один ручний кейс у середньому займає 8 хвилин, отже повний ручний прогін — 96 хвилин. Автотест виконує кожен кейс приблизно за 10 секунд, а весь suite — за 120 секунд. Таблиця має зберігати щонайменше: - назву test suite або user journey; - кількість автоматизованих кейсів; - середній час ручного кейсу та всього suite; - середній час автоматизованого кейсу та всього suite; - кількість запусків за обраний період; - розраховану дельту часу. Кейси потрібно явно переводити з manual backlog до automation coverage. Інакше легко одночасно рахувати той самий обсяг як ручну та автоматизовану роботу.
Модалки для Test і Suite мають схожий заголовок та форму. Спільний helper параметризується `artifact_type`, але лише там, де це справді одна поведінка; різні postconditions залишаються окремими й читабельними. Після Save suite перевіряється за її назвою у списку. Демонстрація кілька разів падає через переплутані helpers і case-sensitive текст `Suite`, що показує цінність короткого red/green циклу для кожного locator.
`SuiteController.create()` приймає `project_id`, `title` і `description`, формує payload та викликає `post` базового controller. Потрібні поля звіряються не лише з документацією, а й з request у browser DevTools. У демо офіційна схема містить сумнівну вимогу до `suite_id` до створення suite, тож real request і response виступають важливою перевіркою контракту. Відповідь Testomat.io загортає основну сутність у поле `data`. Після `response.json()` тест бере `response_data["data"]` і валідує саме цю вкладену структуру.
Перевірка «порожній проєкт» не підходить для довільного existing project. Новий `is_loaded` спирається на стабільний sidebar/navigation, який існує і для порожнього, і для заповненого проєкту. Далі тест відкриває dropdown створення артефактів і додає suite. Пошук locator уточнюється через видимий текст та структуру модалки, а не через крихкі CSS-класи іконки.
Локально 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 тестованої системи.
Після зеленого linter smoke tests падають. Рекомендований порядок діагностики: відтворити точну pipeline-команду локально, звузити запуск до suite, а потім до одного тесту. Якщо тест проходить окремо, але падає у suite, треба шукати shared state, порядок виконання, fixture scope або неповне очищення browser context. Локальний і CI runner також відрізняються потужністю, швидкістю, браузерним режимом і доступами. Тому timeout або race condition може проявлятися лише на одній машині. Logs і artifact trace важливіші за припущення про причину.
Allure залишається потужним звичним рішенням; Monocart згадується як конкурент. Але складний репортинг не є першою потребою невеликого стабільного suite. Тест насамперед має бути зрозумілим розробнику й давати швидкий діагностичний сигнал. Якщо падіння стабільне та відтворюване, Playwright trace часто містить достатньо даних без додаткової системи звітів. Traces можна автоматично зберігати лише для невдалих запусків. Розвинена агрегація стає виправданою при великій кількості тестів, кількох паралельних запусках або потребі бачити історичні тенденції. Якщо ж у suite тисячі UI-тестів, це окремий сигнал перевірити архітектуру покриття, а не лише покращувати звіт.
У спрощеній моделі 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.
Для унікальної назви використовується Faker. Вираз із назвою компанії перетворюється на змінну через створений postfix template, змінна перейменовується на змістовну `target_suite_name` і передається в метод створення. Непотрібні вбудовані postfix templates можна вимикати, щоб список підказок не заважав. Водночас експеримент із власним `.var` показує межу автоматизації: якщо шаблон не залишає курсор у корисному місці, його треба виправити, а не пристосовувати робочий процес до невдалого шаблону. Сценарій запускається й проходить послідовно: авторизація, створення проєкту, закриття README, відкриття діалогу створення тесту. У режимі паузи перевіряється DOM і вибирається текст `Select suite for test`; для нього додається шаблон `get_by_text(...)`, після чого `expect(...).to_be_visible()` підтверджує появу модального вікна. Якщо попередній debug-процес ще приєднаний, повторний запуск може чекати на його завершення. Після коректного продовження або зупинки процесу тест проходить. Наприкінці тест перейменовується відповідно до перевірюваної поведінки, а не до проміжних технічних кроків.
Першим кандидатом є довгий наскрізний P0-сценарій: checkout, реєстрація, основний бізнес-флоу тощо. Він швидко проходить через найбільшу кількість сторінок, API та станів, тож одночасно знайомить автора тестів із широкою частиною продукту. Автотест можна уявити як шлях у графі: кроки — це вузли, а різні переходи утворюють гілки. Після покриття найдовшого маршруту коротші сценарії часто повторно використовують уже реалізовані вузли. Це робить наступні тести дешевшими. Для кожного test suite варто зафіксувати кількість кейсів, середній ручний час і час автоматизованого прогону. Наприклад, якщо checkout вручну займає 20 хвилин, а автоматично — 30 секунд, дельта кожного запуску є наочною цінністю.