Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
У відео рекомендовано API preconditions, reused authenticated state та незалежні test data.
Поточна документація Playwright рекомендує не комітити auth state і використовувати окремий account на parallel worker, якщо tests змінюють shared server-side state. Конкретні fixtures, directories та worker APIs слід звіряти з версією Playwright у проєкті.
Практика курсу на YOY, домашні завдання та формат ПМП →Автоматизуйте створення user і community, перевірте її public page, відредагуйте дані та підтвердьте результат після повторної авторизації. Зафіксуйте, які preconditions варто перенести з UI в API лише після першої робочої версії.
Один відтворюваний test із незалежними даними та явними перевірками state transition.
Генерацію важливих test data краще явно виконувати на початку тесту й передавати результат у helper, а не непомітно ховати всередині `registerUser()` чи `createCompany()`. Так сценарій показує свої preconditions, а той самий expected object доступний для подальших assertions. Business step може повернути оновлену модель, якщо система присвоїла ID, status або інші server-generated поля.
[Дивитися з 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.
Локальна примітивна змінна на кшталт `int` і об’єкти або масиви мають різне представлення в пам’яті. Для масиву примітивів або посилальних типів змінна веде до області в heap; масив `String` містить посилання на окремі рядки. Простий друк масиву не показує його елементи так само зручно, як друк колекції: для масиву в демонстрації потрібне явне перетворення через `Arrays.toString(...)`. Коли об’єкт передається в `System.out.println(...)`, Java неявно звертається до його `toString()`. Для маленького експерименту автор запускає окремий `main`, щоб не проходити весь UI-тест. При цьому test framework hooks, preconditions і postconditions не запускаються; якщо вони важливі для поведінки, перевірку потрібно залишити звичайним тестом.
Projects endpoint повертає колекцію проєктів із title та id. Для прикладу обирається проєкт Manufacture Light, у межах якого потрібно створити test suite. Початковий лінійний сценарій розділяється на methods для login, projects і suites. Кожен method отримує тільки потрібні йому дані: token, project name/id та payload. Це підготовка до винесення API-логіки в controllers.
[Дивитися з 32:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=1920s). Manual QA тепер простіше згенерувати system tests проти повного test environment, використати API preconditions і автоматизувати ticket/report workflow через CLI або MCP. Аналогічно DevOps швидше будує CI/CD та preview environments: subdomain, DNS, application і database lifecycle для кожного PR. AI підсилює кожну роль, але якість результату залежить від її предметної експертизи.
Повторювані `@BeforeAll` і `@AfterAll` замінюються JUnit 5 extension. `WebDriverLifecycleExtension` реалізує `BeforeAllCallback` та `AfterAllCallback`: до тестів ініціалізує driver через provider, після тестів закриває його. Клас підключається через `@ExtendWith`, тому setup/teardown більше не дублюються в кожному test class. Окремий login extension виконує авторизацію перед тестовим класом. Такі розширення дозволяють комбінувати потрібні preconditions без спільного base class. Наприкінці до wrapper додається `findByText(...)`, який будує XPath і повертає той самий тип actions; тест запускається після виправлення синтаксису локатора.