Playwright trace
Trace містить actions, DOM snapshots, console і network details; це корисний debugging artifact, який може містити чутливі headers або payloads.
Як упровадити автоматизацію мануальному QA та довести її ефективність →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Журнал невдалої гіпотези
Візьміть одну реальну помилку з automation-коду.
Запишіть початкову гіпотезу, evidence, відхилений варіант і root cause.
Сформулюйте правило, яке допоможе розпізнати подібний збій наступного разу.
Один короткий debugging record із посиланням на документацію або runtime output.
Assertions, status codes і реальний debugging
Після create виконується `GET` і response data порівнюються з generated input. Помилки `400`/`500` розбираються через actual request/response, а не через здогад. Відео навмисно залишає неідеальний demo API і live debugging. Це добре показує межу між client defect, unstable shared test API і real server defect.
Відтворення authorization flow в API client
Демо послідовно відтворює open login page, authenticate user, follow location/callback, extract authorization code і exchange it for tokens. Cookies оновлюються між кроками, тому shared state має бути explicit. Велика частина демо — live debugging невірного client/redirect та reverse engineering кроків. Практичний висновок: автоматизувати лише documented grant, а browser trace використовувати для пошуку discrepancy.
Повторити, запустити, зламати й виправити
Мінімум для кожного відео — повторити показаний сценарій, запустити тест і самостійно розібратися з проблемами, якщо UI, API або залежності вже змінилися. Після цього варто придумати ще кілька тестів. Курс навмисно веде від сирого синтаксису через повторні рефакторинги до KISS, DRY, SOLID і доречних patterns: цінність дає власний досвід контрольованої помилки, а не готова «ідеальна» архітектура з першого дня.
Навчання через контрольовані проблеми
Перший автотест пропонується буквально повторити за викладачем. Навіть при точному повторенні неминуче виникнуть проблеми із запуском, середовищем або деталями коду. Це не збій курсу, а запланована частина навчання. Ключова ідея — дати учаснику реальну проблему в контрольованому контексті, де зрозуміло, що саме він намагається запустити і який результат очікується. Так формується практична навичка діагностики, а не лише знання абстрактних визначень.
Код як орієнтир, а помилки як частина навчання
[Дивитися з 00:50](https://www.youtube.com/watch?v=FQsfjR_iHoE&t=50s). Автор визнає, що під час демонстрації генерації коду не завжди пояснював, які рішення вдалі, а які потребують покращення, і обіцяє додаткові матеріали. Водночас він радить не копіювати готовий стан механічно: згенерувати власний варіант, запустити його, перевірити фактичну поведінку й лише потім порівняти з репозиторієм. LLM може додати зайві функції, вигадати API або створити код, який не запускається. Тому робочий цикл має виглядати так: невелика генерація → запуск → спостереження помилки → уточнення запиту або питання ментору → виправлення. Репозиторій допомагає локалізувати розбіжність, але не замінює власної діагностики.
Що дають невдалі спроби
Проби й помилки показують межі простого та складного рішення. Неправильні дані або некоректна дія можуть відкрити несподівану поведінку системи й навіть знайти дефект, якого не було видно в позитивному сценарії. Коли інструмент чи framework поводиться неочікувано, доводиться читати документацію, шукати пояснення й доходити до root cause. Саме цей шлях формує переносиме розуміння того, як технологія працює, а не лише пам’ять про готову послідовність команд.
CLI для експерименту, script для повторення
CLI економніше за довгу MCP-взаємодію для короткої перевірки. Але якщо дію треба повторювати — regression check, bug verification або scraping — краще один раз згенерувати й зберегти script. Агент, який щоразу імпровізує новий набір CLI-команд, створює різну поведінку й ускладнює debugging.
Коли краще видалити проєкт і почати з нуля
Видалення проєкту зі списку Recent у PyCharm прибирає лише запис IDE, а не файли з диска. Щоб повністю почати заново, потрібно закрити проєкт, відкрити його розташування через Finder або Explorer і видалити конкретну папку. Для навчального проєкту без цінних змін повторне створення інколи дешевше за довгий ланцюг випадкових виправлень. Початківець може вирішити одну помилку порадою з інтернету, створити іншу й настільки відійти від початкової конфігурації, що діагностика стане складнішою. Це не правило для робочих репозиторіїв із незбереженими даними: перед видаленням завжди треба перевірити, що цінних змін немає. Той самий принцип переноситься на LLM-чат. Якщо перша відповідь повела не туди, варто почати новий контекст із кращим описом середовища, цілі й помилки. Після розв’язання корисно спитати: який початковий prompt одразу дав би достатньо контексту. Так невдалий шлях перетворюється на навчальний матеріал.
AI як помічник для конкретного selector
HTML конкретного елемента можна передати моделі й попросити locator для Playwright або Selenium, уточнивши правила про allowed attributes і partial match. Це швидше за вивчення синтаксису складного XPath, але результат треба перевірити на сторінці. Ще надійніше — мати read access до frontend source, знайти компонент і додати стабільний атрибут у тому самому delivery process.
Витоки стану у RestAssured і пошук правильного endpoint
Перший request до suites повертає `400`, бо повторно використана mutable `RequestSpecification` зберегла form parameters від login request. RestAssured накопичує налаштування у стані specification, тому вона не повинна мутуватися і перевикористовуватися між різними requests. Виправлення — повертати нову specification із factory method для кожного request. Після цього уточнюється endpoint path: запит має містити API prefix, project id і suites resource. Потім `GET` повертає список suites з їхніми id, type і title.