Attachments
Фіксує API та media types для screenshots і інших diagnostic files.
4. Allure репорт, основи та інтеграція в CI → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Не публікуйте дані робочого проєкту
Перед запитанням або прикладом приберіть domains, secrets, персональні дані й identifiers зі screenshots, HTML та endpoint fragments.
Практика курсу на YOY, домашні завдання та формат ПМП →Перший варіант 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.
Коли потрібен Allure і з чого він складається
Повноцінний reporting — це додаткова система, яку доведеться оновлювати й підтримувати. Якщо команді достатньо logs, screenshots, traces і простого HTML report, не варто автоматично додавати Allure лише через популярність. Він доречний, коли потрібні історія, структуровані steps, attachments і спільна точка перегляду результатів. Екосистема має три практичні шари: Allure CLI генерує report; language binding формує сумісні result files; framework adapter на кшталт `allure-pytest` підключається до конкретного test runner. У відео також прямо згадано ризик telemetry та походження продукту: перед adoption треба перевірити актуальну політику даних і вимкнути необов’язкову аналітику відповідно до правил організації.
Консольний запуск, HTML report і Git hygiene
Запуск простої команди `pytest` у терміналі відтворює спосіб, у який suite згодом стартуватиме на CI. Така перевірка важлива: запуск через IDE може мати інший working directory, environment або власні параметри. `pytest-html` створює початковий звіт зі статусами тестів і доступними логами. Його достатньо для першої діагностики на CI: знайти failed test, переглянути повідомлення, а потім локально відтворити проблему з trace. Звіт не замінює повну observability, але дає мінімальний переносний артефакт. Каталоги з HTML-звітами, screenshots і traces додаються до `.gitignore`. Це результати конкретного запуску, а не вихідний код; їх треба публікувати як CI artifacts, а не комітити в репозиторій.
Screenshots, traces та Allure steps
При failure fixture може додати screenshot і trace до результату через Allure attachments із відповідним content type. Screenshot після завершення тесту інколи фіксує стан запізно, тому Playwright trace залишається ціннішим джерелом послідовності дій. Публічні дії Page Object позначаються `@allure.step`, щоб report показував бізнес-зрозумілі кроки, а не лише назву тесту. Приватні helpers, constructors і прості properties не потребують окремих steps: вони створять шум без корисного контексту.