Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Playwright радить використовувати first() і last() обережно: після зміни сторінки вони можуть вибрати інший елемент. Краще сформувати унікальний locator за роллю, назвою або іншим стабільним контрактом.
Дає first-party warning про feature-coupled step definitions і duplication, центральні для критики уроку.
Чому критикують BDD і Cucumber → Першоджерело ↗Показує first-party end-to-end CI sequence для checkout, Python, dependencies, browsers, pytest і trace artifact.
2. Практика та написання пайплану CI/CD → Першоджерело ↗First-party on-device transcription module для SpeechAnalyzer з system-managed locale assets; support потрібно перевіряти для конкретної locale та device.
Корисні застосунки та їхнє призначення →Створити DOM fixture з двома forms і однаковими field identifiers.
Підтвердити strictness failure для global locator.
Звузити пошук до visible container.
Scoped locator проходить без .first і .nth().
Знайдіть у власному тесті інтерактивний елемент, який зараз шукається за CSS-класом або вкладеною структурою.
Перевірте його role та accessible name у Accessibility Tree.
Замініть локатор на get_by_role(..., name=...) і запустіть цільовий тест.
Локатор однозначно знаходить потрібний елемент, а тест проходить без nth(), first або прив’язки до CSS оформлення.
Playwright у strict mode очікує один елемент для дії або перевірки. Загальний локатор `h3` повертає багато заголовків, тому тест падає. `first()` технічно усуває множинність, але не гарантує, що обрано саме потрібний проєкт: перший елемент може виявитися зовсім іншим. Надійніший підхід — звузити локатор за змістом, наприклад через роль і `name` або через `filter(has_text=target_project)`. `first()` доречний лише тоді, коли порядок є частиною контракту, а не способом приховати нечіткий селектор.
[Дивитися з 01:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=90s). Початковий end-to-end flow: створити user, створити community, перевірити її сторінку та редагування. Уже тут видно реальні edge cases: auto-generated URL під час створення не обов’язково поводиться так само під час edit, mobile-first layout відрізняється на desktop, а payment merchant потребує окремого test configuration і не має використовувати production credentials.
Базовий onboarding для всіх рівнів включає documentation, доступи, checkout репозиторію та перевірку Jira/CI. Наступну невелику задачу варто обрати за конкретним плюсом, заради якого людину наймали: fintech, maps, CAPTCHA, OTP чи інша domain expertise. Від senior очікується ширше дослідження infrastructure, access, environments і rate limits; middle може зосередитися на локальній реалізації.
[Дивитися з 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.
Fallback будує context, створює page, авторизується, переходить до Free проєкту й записує `storage_state`. Після цього та сама page передається тесту через `yield`, щоб сценарій продовжився без повторного відкриття вкладки. Під час демонстрації код кілька разів дублюється для швидкої перевірки, а потім уточнюється. Ключовий критерій — окремий Free test має проходити самостійно після видалення всіх локальних state-файлів.
Кілька цін збираються в типізований список, наприклад `list[float]`. `max(prices)` знаходить найбільше значення, а перший елемент можна порівняти з ним, щоб перевірити сортування «від більшої ціни». Навіть коротку, але предметно важливу логіку пропонується оформити функцією на кшталт `is_first_price_highest(prices)`. Назва пояснює вимогу краще, ніж вкладене порівняння всередині великого тесту.
Якщо mobile client переважно відмальовує backend data, основну логіку варто автоматизувати на API-рівні, а на mobile залишити приблизно десяток ключових revenue flows. Якщо ж client містить значну локальну логіку, UI/component coverage потрібно більше. Validation, яка живе всередині форми, доречно перевіряти component test через native framework. Просте відображення backend-масиву краще глибоко перевірити на backend, а на реальному device пройти під час regression. Flaky E2E може вказувати не лише на поганий тест, а й на нестабільність, яку бачать користувачі.