Playwright trace
Trace містить actions, DOM snapshots, console і network details; це корисний debugging artifact, який може містити чутливі headers або payloads.
Як упровадити автоматизацію мануальному QA та довести її ефективність →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Журнал невдалої гіпотези
Візьміть одну реальну помилку з automation-коду.
Запишіть початкову гіпотезу, evidence, відхилений варіант і root cause.
Сформулюйте правило, яке допоможе розпізнати подібний збій наступного разу.
Один короткий debugging record із посиланням на документацію або runtime output.
Playwright Debugging Tests
Підтверджує й актуалізує поняття уроку, пов’язані з Playwright Inspector.
2. Storage state, cookie manipulation, дебаг зникаючих елементів → Першоджерело ↗Running and debugging tests — Playwright Python
Фіксує headless default і прапорець --headed.
Повторити, запустити, зламати й виправити
Мінімум для кожного відео — повторити показаний сценарій, запустити тест і самостійно розібратися з проблемами, якщо UI, API або залежності вже змінилися. Після цього варто придумати ще кілька тестів. Курс навмисно веде від сирого синтаксису через повторні рефакторинги до KISS, DRY, SOLID і доречних patterns: цінність дає власний досвід контрольованої помилки, а не готова «ідеальна» архітектура з першого дня.
Навчання через контрольовані проблеми
Перший автотест пропонується буквально повторити за викладачем. Навіть при точному повторенні неминуче виникнуть проблеми із запуском, середовищем або деталями коду. Це не збій курсу, а запланована частина навчання. Ключова ідея — дати учаснику реальну проблему в контрольованому контексті, де зрозуміло, що саме він намагається запустити і який результат очікується. Так формується практична навичка діагностики, а не лише знання абстрактних визначень.
Код як орієнтир, а помилки як частина навчання
[Дивитися з 00:50](https://www.youtube.com/watch?v=FQsfjR_iHoE&t=50s). Автор визнає, що під час демонстрації генерації коду не завжди пояснював, які рішення вдалі, а які потребують покращення, і обіцяє додаткові матеріали. Водночас він радить не копіювати готовий стан механічно: згенерувати власний варіант, запустити його, перевірити фактичну поведінку й лише потім порівняти з репозиторієм. LLM може додати зайві функції, вигадати API або створити код, який не запускається. Тому робочий цикл має виглядати так: невелика генерація → запуск → спостереження помилки → уточнення запиту або питання ментору → виправлення. Репозиторій допомагає локалізувати розбіжність, але не замінює власної діагностики.
Як працювати з прикладами
Рекомендований цикл: прочитати пояснення, запустити файл, подивитися console output, знайти рядок, який його створив, а потім змінити дані й повторити запуск. Така практика розвиває здатність читати Python, формулювати точніші задачі для ШІ, описувати дефекти та предметно обговорювати код із розробниками.
`try` та конкретний `except`
У `try` розміщують лише операцію, яка очікувано може впасти, а `except ValueError` обробляє конкретний failure type. Широке `except Exception: pass` стирає сигнал і ускладнює debugging. Selenium, filesystem, network і parsing мають різні exception classes, які слід розрізняти.
Ініціалізація Faker і зрозуміла назва даних
Перший виклик виправляється після звірки з API: треба створити екземпляр `Faker()`, а вже потім викликати його provider, наприклад `fake.password(length=10)`. Повторні запуски демонструють різні значення. Змінна називається `invalid_password`, щоб тест явно пояснював роль даних. Практична межа рандомізації: при падінні варто логувати або зберігати згенероване значення чи seed, інакше дефект може бути важко відтворити.
Діагностика hover-різниці на CI
Trace показує реальну причину: на CI hover відбувся, але очікуваний UI state не став видимим так, як локально. Це звужує проблему з абстрактного «тест падає на CI» до конкретної взаємодії браузера й locator assertion. У демонстрації перевірка адаптується для CI/headless режиму, а також розглядається примусова взаємодія. Такий workaround треба застосовувати лише після перегляду trace: інакше легко приховати реальний дефект сторінки або тесту.
Що дають невдалі спроби
Проби й помилки показують межі простого та складного рішення. Неправильні дані або некоректна дія можуть відкрити несподівану поведінку системи й навіть знайти дефект, якого не було видно в позитивному сценарії. Коли інструмент чи framework поводиться неочікувано, доводиться читати документацію, шукати пояснення й доходити до root cause. Саме цей шлях формує переносиме розуміння того, як технологія працює, а не лише пам’ять про готову послідовність команд.
CLI для експерименту, script для повторення
CLI економніше за довгу MCP-взаємодію для короткої перевірки. Але якщо дію треба повторювати — regression check, bug verification або scraping — краще один раз згенерувати й зберегти script. Агент, який щоразу імпровізує новий набір CLI-команд, створює різну поведінку й ускладнює debugging.
Коли краще видалити проєкт і почати з нуля
Видалення проєкту зі списку Recent у PyCharm прибирає лише запис IDE, а не файли з диска. Щоб повністю почати заново, потрібно закрити проєкт, відкрити його розташування через Finder або Explorer і видалити конкретну папку. Для навчального проєкту без цінних змін повторне створення інколи дешевше за довгий ланцюг випадкових виправлень. Початківець може вирішити одну помилку порадою з інтернету, створити іншу й настільки відійти від початкової конфігурації, що діагностика стане складнішою. Це не правило для робочих репозиторіїв із незбереженими даними: перед видаленням завжди треба перевірити, що цінних змін немає. Той самий принцип переноситься на LLM-чат. Якщо перша відповідь повела не туди, варто почати новий контекст із кращим описом середовища, цілі й помилки. Після розв’язання корисно спитати: який початковий prompt одразу дав би достатньо контексту. Так невдалий шлях перетворюється на навчальний матеріал.