Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Урок радить узгоджувати версії Allure CLI та Python integration.
allure-pytest package metadata pin-ить ту саму версію allure-python-commons і вимагає pytest>=4.5.0, але не оголошує dependency або version matrix для Allure CLI. Сумісність генератора й adapter треба доводити pipeline run.
Package metadata commit d420cff86a6bb4a9b42cd16164cd5828b84a24ef перевірено 2026-07-31.
4. Allure репорт, основи та інтеграція в CI →Для запуску Python-тестів у CI потрібно відтворити ті самі базові дії, що й локально: отримати код, встановити Python і залежності, окремо встановити браузери Playwright, запустити lint/format checks та потрібний набір тестів. `pipeline` описує весь процес, а `stage`, `job` і `step` — його менші етапи; точна вкладеність і назви залежать від GitHub Actions, GitLab CI, Jenkins, TeamCity, Bamboo чи іншої системи. Найпоширеніший декларативний формат — YAML. Він дає змогу зберігати pipeline поруч із кодом і однаково описувати послідовність команд, образ середовища, залежності між jobs та умови запуску без окремої мови програмування для кожного CI-продукту.
У CI перед тестами теж потрібен крок встановлення браузерів. Підготовка runner має відтворювати локальні передумови явно; наявність залежності у `requirements.txt` не замінює цього кроку. Практично варто встановлювати лише ті браузери, які справді запускає pipeline. Це скорочує час і обсяг завантаження без нового шару конфігурації.
CLI встановлюється як системний інструмент, а `allure-pytest` додається до Python dependencies. Pytest налаштовується зберігати машинні результати в `allure-results`; цю директорію не комітять. Smoke і regression jobs завантажують свої `allure-results` як artifacts. Publish job завантажує їх, встановлює сумісну версію Allure CLI та виконує `allure generate`. Старі Playwright HTML artifacts можна прибрати, якщо Allure справді стає єдиним report і не втрачає потрібної діагностики. Версії CLI, Python binding і pytest adapter мають залишатися сумісними. Їх не слід незалежно оновлювати без pipeline verification, бо format results і генератор розвиваються окремо.
Workflow починається з назви та triggers. Для перевірки змін використовується `pull_request`, для регулярного прогону — `schedule`, а `workflow_dispatch` дозволяє запустити вибраний набір вручну. Scheduled run є прийнятним компромісом, коли deployment events або сам delivery pipeline ще нестабільні, але команді вже потрібен регулярний feedback. Перша job виконує checkout репозиторію, налаштовує `uv` і Python, встановлює dependencies, запускає Ruff та format check. Checkout обов’язковий, бо runner стартує без коду проєкту.
Fix комітиться й повторно запускається в pull request. Linter і smoke можуть стартувати паралельно, щоб базова функціональна перевірка не чекала на завершення статичного аналізу; точна залежність між jobs визначається вимогами проєкту. Після оновлення п’ять smoke tests проходять. Практичний цикл завершено повним ланцюжком: CI failure → artifact → локальний Trace Viewer → вузька зміна → повторний зелений smoke run.
Якщо кандидат описує CI pipeline, parallelization, sharding, self-hosted runners і підготовку database state перед deployment, окреме базове опитування синтаксису може не додати сигналу. Натомість interviewer просить пояснити, як саме було реалізовано рішення, які trade-offs виникли й що кандидат робив особисто.
[Дивитися з 08:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=480s). Досвідчений engineer із точним plan може реалізувати frontend, backend і частину deployment pipeline, використовуючи готову design system та API contract. Frontend має знати, який resource і endpoint запросити; backend — який response повернути; shared components і design tokens дають повторюваний UI. AI допомагає заповнити реалізацію, але не визначає самостійно правильні boundaries і product behavior.
Типовий невдалий варіант: manual test cases уже містять steps, але автоматизатор повторно перекладає їх у Gherkin, а потім створює step definitions. Одна дія існує як feature text, regex/parameterized step і code implementation. Різні автори формулюють однакові steps по-різному, тому повторне використання швидко руйнується. Management може вимагати кількість automated scenarios або «читабельний для business report», але потім не відкривати ці reports. У такій ситуації Cucumber не забезпечує BDD: він лише додає maintenance cost команді automation. Ознака справжнього BDD — scenarios використовуються для спільних рішень, а не лежать наприкінці pipeline.
Перед CI-запуском переглядаються pytest markers: частина тестів переноситься зі smoke до regression, окремо позначаються API, web і Selenium paths. Після відкриття pull request треба ще раз перевірити diff, reviewers і checks, щоб випадково не опублікувати зайві файли або credentials. Перший pipeline закономірно знаходить lint і formatting problems. Їх виправляють локально тими самими командами, що виконує CI, комітять і повторюють запуск. CI тут є відтворюваною перевіркою, а не заміною локального feedback loop.
Теза «тести без CI нікому не потрібні» занадто категорична. На ранньому етапі локальний запуск поруч із розробником може дати швидший і корисніший feedback, особливо коли deployment pipeline, runners або доступи ще нестабільні. Спочатку команда має довіряти тестам і вміти швидко зрозуміти причину падіння за report, trace, screenshot чи video. Довгі або нестабільні suites не можна бездумно ставити на критичний шлях hotfix deployment: зайняті runners і нестача ресурсів створять чергу для всієї команди. CI-інтеграцію варто нарощувати після того, як визначено мету набору, тривалість, стабільність і місце його запуску.