Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
DB setup може обійти validation, events, audit, cache invalidation і зовнішню синхронізацію. Використовуйте його лише там, де команда явно прийняла direct database contract для test support.
Автомтизація баз даних та що з тим робити та що знати →Для одного business flow перелічіть validation, events, audit і data transformations між API та database.
Визначте, які properties доводить unit, integration та end-to-end test.
Якщо direct DB setup залишається, задайте connection ownership, transaction boundary і cleanup для parallel workers.
Test matrix без дублювання framework behavior і з явним direct-DB ceiling.
Вибрати один user flow і намалювати client, gateway, services, databases і brokers.
Позначити synchronous і asynchronous contracts, state setup і failure boundaries.
Для кожної boundary записати одну contract check і одну end-to-end check.
Одна діаграма, за якою видно, де готувати data і як локалізувати test failure.
Пройти короткий flow через Codegen або CLI.
Зберегти generated draft у test file.
Адаптувати locators і data setup до наявного project contract.
Запустити test і переглянути trace.
Зафіксувати, що саме AI зекономив і що вимагало manual review.
Один repeatable green test із trace та короткою оцінкою saved time.
Під час демонстрації спосіб виклику агентів у Codex був неочевидним, а конфігурація імпортувалася з іншого agent setup.
Станом на 2026-07-31 офіційна документація описує subagent workflows як enabled by default у current Codex releases. Делегування можна запросити прямо або закріпити applicable AGENTS.md чи skill instructions; agent threads видно в app, CLI та IDE.
Перевірено 2026-07-31; точна версія Codex у відео не надана.
Як налаштувати мультиагентне середовище →У відео рекомендовано API preconditions, reused authenticated state та незалежні test data.
Поточна документація Playwright рекомендує не комітити auth state і використовувати окремий account на parallel worker, якщо tests змінюють shared server-side state. Конкретні fixtures, directories та worker APIs слід звіряти з версією Playwright у проєкті.
Практика курсу на YOY, домашні завдання та формат ПМП →Створення або читання сутності через API проходить routing, application logic, database access і serialization, тому сотні setup-запитів накопичують час. Прямий запит до database інколи виконується за кілька мілісекунд і може бути корисним для підготовки або пошуку test data. У Java типовим низькорівневим контрактом є JDBC; у Python — драйвер конкретної СУБД, який зазвичай підтримує Python DB-API. Для підключення потрібні host/URL, database/schema, credentials і driver. Секрети не мають бути в коді, а тестовий користувач БД повинен мати мінімальні права. Прямий insert не завжди еквівалентний product operation: він може обійти validation, events, audit, caches та синхронізацію. Тому DB setup доречний лише для сутностей, де команда явно приймає такий контракт.
Курс орієнтований на кодову автоматизацію, а не на record/playback чи no-code рішення. Як цільову систему використано Testomat.io: курс охоплюватиме UI та окремі API-операції. Автор рекомендує встановити JetBrains Aqua, а Java/JDK завантажити безпосередньо через IDE. Gradle або Maven знадобляться для керування збіркою, залежностями та консольного запуску тестів.
У CI перед тестами теж потрібен крок встановлення браузерів. Підготовка runner має відтворювати локальні передумови явно; наявність залежності у `requirements.txt` не замінює цього кроку. Практично варто встановлювати лише ті браузери, які справді запускає pipeline. Це скорочує час і обсяг завантаження без нового шару конфігурації.
Практичний 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 не буде надійним.
Варто розуміти порядок, у якому test runner завантажує модулі, створює suite/test fixtures, запускає setup, test і teardown. Declaration задає ім'я та тип, assignment присвоює значення, а runtime initialization створює фактичний стан під час виконання програми. Точні терміни залежать від мови, але практичне питання однакове: коли ресурс уже існує й хто ним володіє. На співбесіді можуть попросити пояснити різницю між class та object, відрефакторити тест або написати надійний locator. Потрібно знати CSS/XPath настільки, щоб читати старий код, і віддавати перевагу user-facing locator API Playwright, коли семантична роль або label точніше виражає контракт.
У Aqua створюється Selenium-проєкт з Java, Gradle і JUnit 5. `group` використовується як простір імен, а `artifact` — як назва конкретного проєкту. Для курсу обрано JDK 17; автор демонструє Amazon Corretto, але радить узгоджувати дистрибутив з проєктною командою. До залежностей додаються Selenium і Selenide; після створення проєкту треба дочекатися завершення Gradle sync.
У Q&A уточнюється, що наведені числа взято з реального suite, а не вигадано для презентації. У ручному account-management сценарії потрібно зареєструвати користувача, змінити роль і перевірити результат; найдовші кейси займають близько 20 хвилин, коротші — близько п’яти, а середнє становить приблизно вісім. Автоматизований тест скорочується до приблизно 10 секунд завдяки підготовці користувача через API, збереженій авторизації або прямій підстановці токена та переходу одразу до потрібної сторінки. Це результат поетапної оптимізації, а не швидкість першої сирої UI-версії.
Ініціалізація `WebDriver` і `WebDriverWait` переноситься з тіла тесту до lifecycle methods. `@BeforeEach` створює новий стан перед кожним тестом, тоді як `@BeforeAll` дає змогу один раз підготувати спільний драйвер для тестів класу. Для стандартного `@BeforeAll` метод і пов'язані поля робляться `static`. Закриття браузера переноситься до `@AfterAll`. Під час демонстрації зайва ініціалізація створює кілька драйверів, тому setup спрощується до одного місця, а teardown залишається обов'язковим. `WebDriverWait` має бути побудований на тому самому instance драйвера, з яким працює тест.
Перша практична ітерація — отримати контрольований доступ до наявного скрипта створення користувачів. Скрипт може приховувати складну синхронізацію з державними або сторонніми системами та створювати валідний mocked-профіль для тестового середовища. Далі варто параметризувати потрібний тип і стан користувача та, за потреби, запускати provisioning за розкладом. Кращий довгостроковий шов — test-support endpoint або інший сервісний контракт для створення сутності з унікальним email та потрібними атрибутами. Його можна спочатку викликати з Postman, Insomnia, Bruno чи IDE HTTP client, а потім перенести в test setup. Endpoint видалення не є автоматично безпечним: треба врахувати зв'язки даних і реальну модель lifecycle.
Створюється Java/Gradle project з group/package naming, JUnit Platform і dependencies. Відео використовує Java 11/17 і пояснює різницю Maven та Gradle як build tools. Repositories та artifact storage потрібні не лише для third-party libraries: компанія може публікувати власні clients і test artifacts. Точні dependency versions мають бути pinned і відтворювані на CI.