retain-on-failure
Playwright pytest tracing mode, який зберігає trace лише для failed tests; default tracing mode у plugin — off.
3. Фікс трейсів на СІ →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Плагін уже має `retain-on-failure`
Через custom fixture architecture у відео вручну інтегровано tracing і pytest hook.
Поточний pytest-playwright plugin підтримує --tracing retain-on-failure. Якщо тест використовує стандартні plugin fixtures, спершу варто перевірити цю option; custom hook потрібен, коли lifecycle контролюється власними fixtures.
Pytest plugin reference
Фіксує --tracing modes, включно з retain-on-failure, та default off.
3. Фікс трейсів на СІ → Першоджерело ↗Актуальний pytest pattern використовує `item.stash`
У відео phase reports записуються як динамічні attributes на test node, наприклад rep_call.
Поточний official pytest example використовує typed StashKey та item.stash. Manual Playwright tracing також не записує pytest assertion як traced action; він показує browser context навколо failure.
Від падіння до trace
Зареєструйте marker smoke і позначте ним один UI test.
Налаштуйте tracing=retain-on-failure.
Навмисно зламайте locator у test environment.
Відкрийте trace.zip і знайдіть failed action, console та network context.
Є відтворюваний failed test і trace, за яким можна назвати точну причину падіння.
Мінімальна tracing fixture і перевірка green path
Tracing helpers приймають `page.context`, тому app fixture не мусить окремо повертати context. `start_tracing()` централізує options, а `stop_tracing_on_failure()` або записує ZIP, або зупиняє tracing без path. Після рефакторингу запускаються Free та Enterprise тести. Вони проходять, а папка traces залишається порожньою — це позитивна перевірка, що successful tests не створюють артефакт.
Перший варіант tracing і проблема дублювання
Запис запускається через `context.tracing.start(screenshots=True, snapshots=True, sources=True)`, а перед закриттям context завершується `tracing.stop(path=...)`. Trace Viewer показує Playwright actions, DOM snapshots, source files і network. Якщо вставити start/stop у кожну низькорівневу fixture, код дублюється, а один session trace змішує кілька тестів. Tracing переноситься у test-scoped app fixtures, щоб кожен тест мав окремий lifecycle.
Чому вбудованої pytest-playwright fixture недостатньо
Проєкт сам контролює `storage_state`, авторизовані та Free contexts, відкриття й закриття page. Через це готові fixtures плагіна не покривають потрібний lifecycle, а tracing доводиться інтегрувати у власний шар. Перед tracing виправляється побічна проблема: Free test відкривав два browser instances, бо вимагав fixture, результат якої не використовував. Видалення зайвої залежності прибирає другий запуск браузера.
Від публічного API до реалізації Locator
[Дивитися з 00:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=0s). Playwright складається з багатьох частин: browser lifecycle, locators, actions, assertions, downloads, reporting і tracing. Щоб відповісти на питання «що відбувається під капотом», автор відкриває реалізацію `Locator`, а не обмежується документацією верхнього рівня. `Locator` зберігає frame і спосіб пошуку елемента, а додаткові умови на кшталт `has`, `hasText` чи visibility-related filters добудовують запит. У Python named arguments роблять таку композицію схожою на Builder без окремого builder class. Практичний висновок: перед створенням власного selector DSL варто перевірити вже наявні аргументи конструктора й методи locator API.
`pytest.ini`: discovery, `addopts` і маркери
У `pytest.ini` задаються каталоги з тестами, шаблони імен тестових файлів і функцій та директорії, які не потрібно сканувати. Це звужує test discovery до структури проєкту й прибирає зайву роботу з `.git`, `.idea`, build-артефактами та кешами. Через `addopts` виносяться параметри, які мають застосовуватися до кожного запуску: verbose output, короткий traceback, відображення output лише для failed tests, strict markers, Playwright tracing і генерація self-contained HTML report. Маркери `smoke`, `regression`, `web` та `slow` реєструються явно, щоб помилка в назві не перетворилася на тихе пропускання потрібної групи. Для traces обирається `retain-on-failure`: артефакт створюється під час тесту, але зберігається лише після падіння. Це практичніший default, ніж trace для кожного успішного тесту, бо архіви можуть швидко зайняти багато місця.
Мовні реалізації, runner і bindings
Playwright має APIs для TypeScript/JavaScript, Python, Java і .NET. Найповніша інтеграція навколо власного runner, fixtures і reporting доступна у Playwright Test для TypeScript/JavaScript; у Python за orchestration зазвичай відповідає pytest та його plugins. Selenium також має офіційні language bindings, які перетворюють API-виклики на WebDriver commands. Окремі команди підтримують Selenium project і browser vendors, тому version compatibility та відмінності bindings залишаються частиною експлуатації. Обидва інструменти — великі multi-language ecosystems. Вибір мови впливає не лише на синтаксис, а й на доступність runner integrations, fixtures, reporters, tracing і швидкість появи нових можливостей.