Дубльований `id` — невалідний HTML, а scope лише workaround
HTML Standard вимагає, щоб id був унікальним у межах element tree. Scope до desktop container може стабілізувати test, але root fix належить frontend markup.
Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
HTML Standard вимагає, щоб id був унікальним у межах element tree. Scope до desktop container може стабілізувати test, але root fix належить frontend markup.
Ім’я, за яким element сприймається assistive technologies і знаходиться role locator; воно формується семантикою HTML та ARIA.
3. Селектори та пошук елементів →Machine-readable files, які test framework adapter записує під час run; Allure Report читає їх для генерації HTML report.
4. Allure репорт, основи та інтеграція в CI →Перед запитанням або прикладом приберіть domains, secrets, персональні дані й identifiers зі screenshots, HTML та endpoint fragments.
Практика курсу на YOY, домашні завдання та формат ПМП →Запуск простої команди `pytest` у терміналі відтворює спосіб, у який suite згодом стартуватиме на CI. Така перевірка важлива: запуск через IDE може мати інший working directory, environment або власні параметри. `pytest-html` створює початковий звіт зі статусами тестів і доступними логами. Його достатньо для першої діагностики на CI: знайти failed test, переглянути повідомлення, а потім локально відтворити проблему з trace. Звіт не замінює повну observability, але дає мінімальний переносний артефакт. Каталоги з HTML-звітами, screenshots і traces додаються до `.gitignore`. Це результати конкретного запуску, а не вихідний код; їх треба публікувати як CI artifacts, а не комітити в репозиторій.
Ще один експеримент — sidebar, який об’єднує кілька LLM interfaces і передає їм виділений на сторінці текст або HTML fragment. Для automation engineer це скорочує шлях від inspect element до prompt: можна вибрати DOM block і попросити запропонувати locator або page object. Це не замінює перевірку selector-а. Згенерований варіант треба оцінити за semantics, uniqueness і stability у реальному DOM, але інструмент прибирає кілька механічних copy/paste дій.
Надійні локатори спрощують не лише написання нового тесту, а й пошук дублювань та рефакторинг наявного набору. Без розуміння HTML одна й та сама кнопка швидко отримує кілька різних локаторів у різних тестах. DOM розглядається як дерево. Кореневий `<html>` містить `<head>` і `<body>`, а вкладені елементи утворюють гілки на різних рівнях. DevTools дає змогу розгортати й згортати ці гілки та бачити, до якого блоку належить потрібний елемент.
Автор представляє односторінкову CSS/XPath шпаргалку для подальшого доповнення. Найпростіший CSS-селектор — ім’я tag, наприклад `div`, `script`, `a`, `li` або `form`. Такий запит знаходить усі елементи відповідного tag і зазвичай потребує додаткового звуження. У DevTools search треба відрізняти результати CSS-запиту від звичайного текстового пошуку.
HTML-вузол має тег, атрибути та вкладений вміст. Атрибут `class` може містити кілька класів, розділених пробілами. CSS надає короткий синтаксис: ```css #search /* елемент з id="search" */ .demo /* елемент із класом demo */ input#search /* input з id="search" */ ``` Текстові локатори краще будувати засобами Playwright, а не намагатися кодувати складний пошук тексту в CSS.
Повторювані checkout, setup `uv`, setup Python та install dependencies винесено у локальний composite action. Input `install-playwright` вмикає браузерні залежності лише для jobs, яким вони потрібні. Це виправдане перевикористання, бо той самий setup уже виконується в smoke і regression jobs. Після тестів workflow завантажує HTML report і Playwright traces як artifacts. Для них задається retention, наприклад 14 днів: це тимчасові діагностичні результати, а не постійне сховище. HTML report зберігається завжди, traces — переважно після failure.
HTML конкретного елемента можна передати моделі й попросити locator для Playwright або Selenium, уточнивши правила про allowed attributes і partial match. Це швидше за вивчення синтаксису складного XPath, але результат треба перевірити на сторінці. Ще надійніше — мати read access до frontend source, знайти компонент і додати стабільний атрибут у тому самому delivery process.
Повноцінний reporting — це додаткова система, яку доведеться оновлювати й підтримувати. Якщо команді достатньо logs, screenshots, traces і простого HTML report, не варто автоматично додавати Allure лише через популярність. Він доречний, коли потрібні історія, структуровані steps, attachments і спільна точка перегляду результатів. Екосистема має три практичні шари: Allure CLI генерує report; language binding формує сумісні result files; framework adapter на кшталт `allure-pytest` підключається до конкретного test runner. У відео також прямо згадано ризик telemetry та походження продукту: перед adoption треба перевірити актуальну політику даних і вимкнути необов’язкову аналітику відповідно до правил організації.
Однакова конфігурація потрібна, щоб локальний запуск і CI поводилися передбачувано. У проєкті фіксуються мінімальні версії `pytest`, `pytest-playwright`, `pytest-html`, Faker та інших залежностей. Це дає IDE, pytest і CI явні передумови замість неявної залежності від локального середовища автора. На початку також показано Local History і Smart Checkout у PyCharm/IntelliJ. Ці інструменти можуть допомогти повернути локальні зміни або розібрати конфлікт під час перемикання гілки, але не замінюють Git-історію та перевірку diff.
Першим джерелом назви сторінки є route: кореневий шлях підказує home page, а змістовний path — конкретний екран. Якщо це SPA або URL не змінюється, наступним джерелом стає видима назва сторінки: `h1`, `h2`, title чи інший семантичний заголовок. Коли framework генерує сторінку переважно з `div`, треба орієнтуватися на мову продукту та стабільні атрибути DOM. Мета — щоб назва в automation-коді відповідала тому, як екран уже називають користувачі й розробники.