Реєстрація strict pytest marker
Мінімальна конфігурація реєструє marker smoke і змушує pytest відхиляти невідомі markers.
Тест із @pytest.mark.smoke збирається без unknown-marker error.
1. Налаштування Playwright та Pytest, простий репортінг →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
git diff --check
Вузька перевірка conflict markers і налаштованих whitespace errors. Вона не доводить правильність або працездатність коду.
Репозиторій як довідник до модулів →uv.lock
uv.lock фіксує точні розв’язані версії для різних Python markers і призначений для version control та відтворюваних установок.
Smoke і regression jobs
Test job повторює підготовку середовища, встановлює Chromium для Playwright і запускає pytest з відповідними markers. Smoke, regression, API та UI перевірки повинні мати явні набори запуску; в міру зростання проєкту їх краще рознести по окремих workflow, якщо вони мають різні triggers, dependencies або час виконання. Markers треба переглядати як продуктову класифікацію, а не разове маркування: smoke suite має залишатися малим і відповідати на питання, чи застосунок узагалі придатний до глибшої перевірки. Regression містить ширше покриття й не повинен блокувати ранній feedback від smoke.
`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 для кожного успішного тесту, бо архіви можуть швидко зайняти багато місця.
Запуск suites і межі повторного state
Після переходу на `uv` набори запускаються через `uv run pytest` і pytest markers на кшталт `smoke` або `regression`. Перший context виконує login та записує state, наступні contexts завантажують цей файл. Перевірка показує, що оптимізація не виправляє помилки очікувань автоматично: тест може падати через неправильний `is_loaded` або інший homepage state. Треба відрізняти проблему повторної авторизації від помилки самої fixture чи assertion.
Класифікація тестів і перший pull request
Перед CI-запуском переглядаються pytest markers: частина тестів переноситься зі smoke до regression, окремо позначаються API, web і Selenium paths. Після відкриття pull request треба ще раз перевірити diff, reviewers і checks, щоб випадково не опублікувати зайві файли або credentials. Перший pipeline закономірно знаходить lint і formatting problems. Їх виправляють локально тими самими командами, що виконує CI, комітять і повторюють запуск. CI тут є відтворюваною перевіркою, а не заміною локального feedback loop.
Base URL, skip markers і відновлення suite
Наступні failures виявляються не проблемою браузера, а конфігурацією: fixture використовує неправильний base URL. Після виправлення route тести знову доходять до цільової сторінки. Також виправляється неправильний виклик `pytest.skip()` на рівні module collection. Для декларативного пропуску тесту потрібен `@pytest.mark.skip` або module-level marker; інакше pytest може пропустити весь модуль або зупинити collection не так, як очікувалося. Негативний login test відкриває sign-in route напряму. Перехід через home page і клік Login не є частиною його контракту, лише додає час і ще одну можливу причину падіння.