Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Показує sync API, injected page fixture, navigation і web-first assertion без залежності від мінливого повного title.
pytest знаходить один test і він проходить у Chromium.
2. Перший автотест на Python з Playwright →[Дивитися з 20:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=1200s). Timeout можна задавати для конкретної operation або централізовано на рівні page/context. Локальні довільні timeout-и у кожному locator виклику ускладнюють поведінку suite, тому корисніше мати послідовну default policy й змінювати її лише для підтверджених винятків. У відео розбираються load states `domcontentloaded`, `load` і `networkidle`, а також події detach, close та navigation timeout. `networkidle` не є універсальним доказом готовності application: сучасна сторінка може мати постійний network traffic. Надійніша перевірка — очікування конкретного observable UI state через locator або web-first assertion. Стабільний element означає, що його bounding box не змінюється протягом послідовних animation frames. Це захищає від кліку в element, який ще рухається або змінює розмір під час layout/animation.
Функція оголошується через `def`, приймає named parameters і може повертати значення. Type hints на кшталт `email: str` та `-> dict[str, str]` покращують navigation і IDE checks, але самі по собі не валідовують input at runtime.
Playwright підтримує тривалий двосторонній канал із browser process і через browser-specific protocol передає команди click, fill, navigation та читання стану. Locator actions мають auto-waiting: перед дією Playwright перевіряє релевантні actionability conditions — наприклад, видимість, стабільність, можливість отримати events і editable state. Це дозволяє тесту формулювати намір «виконай click для цього locator», а orchestration layer бере на себе очікування готовності елемента в межах timeout. Auto-waiting не усуває потребу в assertion: після дії все одно треба перевірити очікуваний результат. Основні browser engines Playwright — Chromium, Firefox і WebKit. WebKit наближає поведінку Safari, але не є повною копією всіх Safari/macOS/iOS інтеграцій. Branded Chrome або Edge можуть запускатися як Chromium channels, проте повну browser matrix потрібно визначати з реальної product analytics і support policy.
На прикладі повторюваних рядків показано `Refactor → Introduce Variable`: PyCharm створює змінну з виділеного виразу й може замінити всі його входження. У демонстрації на macOS використовується `⌘⌥V`; на Windows або Linux слід дивитися актуальне скорочення безпосередньо в меню IDE. Так само винесено повторювані значення `classical` і `BDD` у зрозуміло названі змінні. IDE підсвічує невикористаний код сірим, тому зайві параметри й імпорти можна швидко знаходити та видаляти. Окрема команда оптимізує імпорти після змін. Для навігації показано: - `⌘B` — перейти до оголошення або реалізації символу під курсором; - `⌘⌥←` і `⌘⌥→` — повернутися до попереднього місця редагування або перейти вперед; - перехід на початок чи кінець рядка замість ручного руху курсора. Головна звичка: спочатку шукати дію в контекстному меню й дивитися її назву та скорочення, а вже потім за потреби змінювати keymap.
Appium і WebdriverIO дають спільний зовнішній API для iOS та Android, але додають кілька шарів комунікації між тестом, Appium server, platform driver і device. Через це сценарії повільніші, а діагностика instability складніша, ніж у native tests. Одна бізнес-дія також може мати різний UI на різних платформах: date picker, введення числа, back navigation і переходи між екранами підпорядковуються різним design guidelines. Відрізняється й lifecycle: після згортання або повернення екран може відновити state з local storage чи повторно звернутися до backend. Спільний тест часто все одно отримує platform-specific branches або окремі page/screen objects.
iOS Human Interface Guidelines і Android Material guidelines задають expected platform behavior. Тестування має враховувати, що calendar, navigation, gestures і accessibility відрізняються між platforms. Мобільний product може бути responsive web, native, hybrid WebView або cross-platform. Hybrid app має native shell і web context, тому автоматизація має розуміти context switching й не трактувати все як однакову UI tree.
iOS та Android мають різні звичні navigation patterns, date pickers, системні кнопки й жести. Те, що інтуїтивно для користувача iOS, може бути незрозумілим на Android, тому UI/UX guidelines обох платформ є практичним джерелом тестових очікувань. Розрізняються web, hybrid, cross-platform і native застосунки. Hybrid app поєднує native shell з WebView-екранами, cross-platform app будується на Flutter, React Native чи Xamarin, а native app реалізується окремо під конкретну ОС.
WebView може мати доступ до native navigation, Bluetooth, secure storage та інших можливостей через інтеграційний шар. Водночас Flutter/React Native rendering і custom components створюють окремі ризики для accessibility та поведінки на різних пристроях. Найпростіша практична accessibility-перевірка — збільшити системний font size й переконатися, що текст не виходить за кнопки, поля та контейнери, а елементи залишаються клікабельними. Також згадуються contrast, tactile feedback і безпечна animation, але детальний аудит цих стандартів винесено за межі відео.
Функції Page Object називаються за дією тест-кейсу й починаються з дієслова; класи, файли, variables і constants позначають сутності або дані. Для однакових дій команда має обрати один словник — наприклад, послідовно використовувати `fill`, `click` і `select`, бажано близько до API обраного framework. Функцію, яка натискає кнопку, не варто називати `openPage`: окрема navigation-функція може відкривати URL напряму, обходячи довгий UI-шлях. Неминучі суперечки на code review краще завершити коротким naming convention у README, а не щоразу вирішувати те саме заново.
Сценарій розширюється: після авторизації тест знаходить поле пошуку, вводить `Manufacture Light`, відкриває проєкт і перевіряє заголовок сторінки. Локатори виносяться у змінні, щоб одне й те саме значення використовувалось для кліку та перевірки. Очікування початкового завантаження документа не гарантує готовність динамічного UI. Після кліку Selenium одразу переходить до `find_element()`, тоді як потрібний компонент ще рендериться. У результаті тест падає не через дефект продукту, а через те, що тест швидший за інтерфейс. `is_displayed()` тут не допомагає, якщо сам `find_element()` уже кинув exception. Синхронізацію треба будувати навколо повторного пошуку елемента, а не навколо одноразової перевірки рано знайденого об’єкта.