Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Першим джерелом назви сторінки є route: кореневий шлях підказує home page, а змістовний path — конкретний екран. Якщо це SPA або URL не змінюється, наступним джерелом стає видима назва сторінки: `h1`, `h2`, title чи інший семантичний заголовок. Коли framework генерує сторінку переважно з `div`, треба орієнтуватися на мову продукту та стабільні атрибути DOM. Мета — щоб назва в automation-коді відповідала тому, як екран уже називають користувачі й розробники.
Учасник пропонує вважати сторінку завантаженою після появи важливих для бізнес-сценарію елементів і контенту, а не лише після формального відкриття. Він порівнює це з метрикою готовності сторінки та одразу ставить питання про межу такого контракту. Основний trade-off — не додати в кожен перехід зайві очікування. Які саме сигнали належать до `isLoaded`, залежить від типу сторінки та наступної дії тесту.
Практичний flow: людина вручну проходить сценарій через Playwright Codegen, передає згенерований код моделі, просить рознести його по наявних page objects, запускає тест і дає trace для наступного review. Генерація відбувається малими порціями, а людина контролює data setup, reuse та фактичний user journey. Для складного enterprise flow з inventory, credit limits, third-party integrations і stateful users автономний agent без domain context не буде надійним.
[Дивитися з 05:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=330s). Suite ускладнюється вертикально: спочатку прямий UI-flow, потім reusable helpers, Page Objects, розширення object model, API preconditions і повторне використання authenticated state. Складніший сценарій може створити другу людину, зареєструвати її на event і перевірити participant list від імені admin. Пізніше ті самі tests мають запускатися в CI, де з’являться окремі environment-specific failures.
На базовому рівні потрібно розуміти primitives/value types, reference/object types, класи, об'єкти та принципи OOP. Із прикладних патернів найчастіше зустрічається Page Object; корисно впізнавати Singleton, Builder, Facade та інші рішення, але не впроваджувати їх без проблеми, яку вони реально спрощують. Page Factory виник навколо старих Selenium-підходів із lazy initialization елементів. Для сучасного Selenium або Playwright його не варто застосовувати за інерцією. У багатопоточному WebDriver framework кожен тест/worker повинен мати власний browser context або driver; спільний mutable driver спричиняє взаємний вплив тестів.
Щоб будувати виклики через крапку, метод Page Object замість `void` повертає поточний тип і завершується `return this`. Так `open()` може повернути `SignInPage`, після чого одразу викликається `loginUser(...)`. У відео цей стиль пов'язують із назвами fluent interface та chain of invocation; у заголовку уроку також використано Chain of responsibility. Повернення `this` зручне для послідовності дій у межах одного Page Object. Повертати з кожного методу наступну сторінку викладач не радить: довгі ланцюжки приховують переходи й ускладнюють code review. Допустимий локальний виняток — компонент або popup, який належить поточній сторінці й природно стає наступним об'єктом взаємодії. Спільні значення, потрібні кільком тестам, переносяться до наявного `BaseTest`, а не дублюються. Для них обирається найвужча достатня видимість, у прикладі — `protected` для класів-нащадків.
Повторюваний login переноситься до `BaseTest`, після чого тест починається з уже відкритої сторінки проєктів. Запуск підтверджує успішну авторизацію, а консольний звіт показує пройдену перевірку `shouldBe(visible)` та її тривалість у мілісекундах. Коли fluent interface утворює довгий вираз, кожну логічну дію варто переносити на окремий рядок. Це не змінює виконання, але дозволяє читати сценарій зверху вниз і швидше співвідносити падіння зі звітом.
Внутрішня функція корисна, коли складна бізнес-дія складається з кількох неочевидних технічних кроків або коли розрахунок потребує предметної назви. Вона зменшує деталі у публічному методі й показує, що не є частиною API класу. Водночас Page Object має залишатися простим. Не варто ділити кожен рядок на helper: виділення виправдане, коли воно називає реальну дію або приховує поточну складність.
Рекомендована послідовність для мануального QA: 1. Написати сирий наскрізний сценарій і навчитися синтаксису Playwright та test runner. 2. Винести повтори у функції. 3. Перейти до класів, Page Object та доречних патернів. 4. Оптимізувати підготовку стану й окремі кроки через API. 5. Додати параметризовані й комбінаторні сценарії. 6. Поступово покривати інші пріоритетні test suites. Перші три місяці можуть дати лише кілька десятків тестів, але кожен із них запускається багато разів локально й у CI. Саме повторюваність створює економію, навіть якщо підтримка нестабільних падінь усе ще потребує уваги.
Сценарій розділяється між `ProjectsPage`, сторінкою окремого проєкту та `ReadmePage`. Для переходів використовуються посилання README й кнопка Edit; якщо немає стабільнішого атрибута, елемент у демонстрації шукається за видимим текстом. Текстовий локатор прийнятний для продукту з однією стабільною мовою, але стає крихким, коли копірайт часто змінюється або UI має кілька локалізацій. Після перемикання мови такі тести масово падають. Автоматизацію повної перевірки локалізацій викладач не рекомендує як першу задачу для початківця: спершу потрібно зрозуміти DOM і стабільні контракти конкретного продукту.