Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Прихований mobile block може залишатися в DOM разом із desktop block. Visibility не робить global locator унікальним; scope до правильного container має бути явним.
3. Селектори та пошук елементів →Порівнює id shorthand, substring match і комбінування tag, classes та attribute.
Кожен selector знаходить лише intended element у відповідному DOM fixture.
3. Селектори та пошук елементів →Playwright abstraction, яка повторно знаходить актуальний DOM element перед кожною action та підтримує auto-waiting і retry-ability.
3. Селектори та пошук елементів →Повторно обчислюваний опис пошуку елемента; Playwright знаходить актуальний DOM element перед кожною дією й поєднує Locator з auto-waiting.
Що має описувати isLoaded →Trace містить actions, DOM snapshots, console і network details; це корисний debugging artifact, який може містити чутливі headers або payloads.
Як упровадити автоматизацію мануальному QA та довести її ефективність →Архів записаних browser actions і diagnostic data, який Trace Viewer показує як timeline, DOM snapshots, logs, network, source і metadata test run.
3. Фікс трейсів на СІ →Надійні локатори спрощують не лише написання нового тесту, а й пошук дублювань та рефакторинг наявного набору. Без розуміння HTML одна й та сама кнопка швидко отримує кілька різних локаторів у різних тестах. DOM розглядається як дерево. Кореневий `<html>` містить `<head>` і `<body>`, а вкладені елементи утворюють гілки на різних рівнях. DevTools дає змогу розгортати й згортати ці гілки та бачити, до якого блоку належить потрібний елемент.
Комбінатор `+` вибирає adjacent sibling: елемент, який розташований одразу після іншого елемента на тому самому DOM-рівні. Це дозволяє знайти input або container відносно стабільного label. Такий локатор залежить від порядку в DOM, тому перед використанням треба перевірити структуру, а не лише візуальне розташування.
Альтернативний спосіб — DevTools breakpoint `Break on subtree modifications` на контейнері. Після Save браузер зупиниться на зміні DOM; покрокове продовження дозволяє знайти проміжні стани `Saving` і `Saved` та побудувати locator. Для перевірки cookie тест ставиться на паузу, у DevTools відкривається Application → Cookies, виконується наступний крок і reload. Так видно, що feature flag дійсно додано до правильного домену до того, як на нього покладатиметься assertion.
Створюється тест, який авторизується в застосунку й шукає проєкт «Python Manufacture». Спочатку кроки пишуться прямо в тесті: відкрити сторінку входу, заповнити email і пароль, натиснути Sign in, знайти поле пошуку. Паралельно досліджується DOM: візуальна фільтрація не обов’язково видаляє непотрібні картки — застосунок може лише приховувати їх через CSS. Через це перевірка має враховувати не тільки наявність вузла в DOM, а й його видимість.
Ще один експеримент — sidebar, який об’єднує кілька LLM interfaces і передає їм виділений на сторінці текст або HTML fragment. Для automation engineer це скорочує шлях від inspect element до prompt: можна вибрати DOM block і попросити запропонувати locator або page object. Це не замінює перевірку selector-а. Згенерований варіант треба оцінити за semantics, uniqueness і stability у реальному DOM, але інструмент прибирає кілька механічних copy/paste дій.
Перед аналізом очікувань виправляється ще одна причина падіння: регістр символів і точне значення атрибута мають збігатися з DOM. Це нагадування не списувати кожен `NoSuchElementException` на повільну сторінку — спочатку слід перевірити сам локатор. `driver.implicitly_wait(10)` задає загальний час очікування для пошуку елементів. Такий механізм може дочекатися присутності вузла в DOM, але не виражає конкретний стан: елемент може існувати, залишаючись невидимим або недоступним для кліку. Для сучасних динамічних сторінок урок рекомендує не покладатися на implicit wait. Тесту потрібна конкретна умова — visibility, clickability, selected state або зникнення — у конкретному місці сценарію.
Першим джерелом назви сторінки є route: кореневий шлях підказує home page, а змістовний path — конкретний екран. Якщо це SPA або URL не змінюється, наступним джерелом стає видима назва сторінки: `h1`, `h2`, title чи інший семантичний заголовок. Коли framework генерує сторінку переважно з `div`, треба орієнтуватися на мову продукту та стабільні атрибути DOM. Мета — щоб назва в automation-коді відповідала тому, як екран уже називають користувачі й розробники.
На Python-проєктах можна зустріти три підходи: зберігати locator tuple, лише CSS/XPath-рядок або вже знайдений `WebElement`. Рядок коротший, але не містить тип пошуку; `WebElement` зручний лише поки DOM-вузол не перерендерився; locator дає змогу безпечно виконувати повторний пошук. Якщо helper має приймати і locator, і `WebElement`, це можна відобразити union type та всередині визначити потрібну expected condition. Така гнучкість виправдана лише коли обидва представлення реально використовуються; для нового коду один locator-based контракт простіший. Wait helper отримує default timeout, але дозволяє локально передати довший для справді повільної операції. Page Object може застосовувати Loadable Component approach: сторінка вважається готовою лише після появи її ключових елементів, наприклад email і password inputs.
У браузерних DevTools вмикається режим вибору елемента на сторінці. Після кліку потрібний вузол одразу знаходиться в HTML, де можна перевірити унікальність майбутнього селектора. У прикладі селектор має знаходити рівно один елемент. Ручний процес — скопіювати значення, повернутися в PyCharm і загорнути його в `page.locator(...)` — повторюється багато разів. Це хороший кандидат для локального шаблону: структура виклику стабільна, а змінюється лише селектор.
Інший recorder записує кроки login-сценарію та дозволяє обрати мову експорту. Згенерований приклад містить `goto`, `fill` і `click`, але не враховує дубльовані `#content-mobile` та `#content-desktop` блоки на сторінці Testomat.io. Через це локатор поля може знайти кілька вузлів і впасти у strict mode. Генератор бачить окрему дію, але не обов’язково розуміє контекст DOM або усталену архітектуру тестів. Код є чернеткою, а не готовим тестом.