Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Показує найкоротший workflow path від checkout до smoke tests без винесення setup у composite action.
Pull request або manual dispatch створює smoke job на ubuntu-latest і запускає pytest marker smoke.
2. Практика та написання пайплану CI/CD →Machine-readable files, які test framework adapter записує під час run; Allure Report читає їх для генерації HTML report.
4. Allure репорт, основи та інтеграція в CI →Файл або набір файлів, створений під час workflow run і збережений GitHub для обміну між jobs або подальшого завантаження.
2. Практика та написання пайплану CI/CD →Test, який упав під час першого run, але пройшов retry. Playwright відрізняє його від passed і failed; default retries дорівнює zero.
Перевірка видимості, тексту або значення, яку Codegen додає через Inspector; вона залишається чернеткою до review і test run.
4. Playwright плагіни та codegen →Архів записаних browser actions і diagnostic data, який Trace Viewer показує як timeline, DOM snapshots, logs, network, source і metadata test run.
3. Фікс трейсів на СІ →Fix комітиться й повторно запускається в pull request. Linter і smoke можуть стартувати паралельно, щоб базова функціональна перевірка не чекала на завершення статичного аналізу; точна залежність між jobs визначається вимогами проєкту. Після оновлення п’ять smoke tests проходять. Практичний цикл завершено повним ланцюжком: CI failure → artifact → локальний Trace Viewer → вузька зміна → повторний зелений smoke run.
Стартовий скрипт можна запустити кнопкою Run або гарячими клавішами. У конфігурації автора: - `Ctrl+Shift+R` запускає файл, у якому зараз стоїть курсор; - `Ctrl+R` повторює попередній запуск. У JetBrains IDE контекст дії часто залежить від поточного курсора або сфокусованого елемента. Перед запуском потрібно перевіряти, який файл і яка конфігурація активні.
Після міграції тест запускається через команду `uv run ...` з консолі, бо це ближче до майбутнього CI-запуску, ніж Run Configuration IDE. Треба перевірити, що виконався потрібний тест і що очікуване падіння справді належить тестовій логіці, а не відсутній залежності чи неправильному шляху. Фінальний крок — створити короткий `README` з мінімальною версією Python, установкою, командами запуску, структурою та правилами внесення змін. Commit message перевіряється вручну: він має називати реальну міграцію на `uv` і підключення Ruff, а не перелічувати випадкові деталі diff.
Змінна отримує тип із присвоєного значення: текст у лапках стає `str`, ціле число — `int`, число з десятковою крапкою — `float`, а `True`/`False` — `bool`. `type(value)` допомагає побачити фактичний тип. Файл можна запускати кнопкою Run в IDE й одразу звіряти оголошені значення з console output.
Workflow починається з назви та triggers. Для перевірки змін використовується `pull_request`, для регулярного прогону — `schedule`, а `workflow_dispatch` дозволяє запустити вибраний набір вручну. Scheduled run є прийнятним компромісом, коли deployment events або сам delivery pipeline ще нестабільні, але команді вже потрібен регулярний feedback. Перша job виконує checkout репозиторію, налаштовує `uv` і Python, встановлює dependencies, запускає Ruff та format check. Checkout обов’язковий, бо runner стартує без коду проєкту.
Pytest fixture може мати scope `session`, `package`, `module`, `class` або `function`. Чим ширший scope, тим рідше створюється ресурс: session fixture — один раз на весь test run, function fixture — окремо для кожного тесту. Код до `yield` виконує setup, а після `yield` — teardown відповідного scope. Ціль уроку — перетворити один негативний login test на параметризований. Тіло сценарію залишається одним, а різні пари email/password та читабельні case IDs передаються як дані.
Credentials, product, company чи іншу сутність не варто фіксувати безпосередньо в тілі всіх тестів: один екземпляр не дає варіативності й приховує проблеми з іншими значеннями. Faker або власний generator має враховувати domain constraints і boundary values, а кожен run — по можливості створювати інший валідний набір. Детермінований seed можна залишити для відтворення падіння.
Selenium 4 використовує стандартизований W3C WebDriver protocol. Client binding надсилає HTTP-команди WebDriver endpoint, а browser-specific driver виконує їх у Chrome, Firefox, Edge, Safari чи іншому підтримуваному браузері. У старішому Selenium 3 застосовувався JSON Wire Protocol. У класичному Selenium flow перед click або input часто використовується explicit wait: client повторно перевіряє умову на кшталт visibility або clickability, а після її виконання надсилає окрему action command. Це створює більше round trips, особливо коли browser session віддалена. Сильна сторона Selenium — широка екосистема vendor drivers і remote providers. Якщо навіть невелика частка користувачів певного браузера означає сотні тисяч людей або браузер входить у договірну support matrix, таке покриття не можна відкидати лише через повільніший test run. У Python-проєкті технічно можна мати і Playwright, і Selenium tests під pytest: Playwright для основного functional suite, Selenium — для вузької cross-browser перевірки. Це виправдано лише реальною вимогою, бо два automation stacks подвоюють dependency, fixture та maintenance surface.
Після переходу на `uv` набори запускаються через `uv run pytest` і pytest markers на кшталт `smoke` або `regression`. Перший context виконує login та записує state, наступні contexts завантажують цей файл. Перевірка показує, що оптимізація не виправляє помилки очікувань автоматично: тест може падати через неправильний `is_loaded` або інший homepage state. Треба відрізняти проблему повторної авторизації від помилки самої fixture чи assertion.
Локально Selenium client, driver і browser часто знаходяться на одній машині, тому додаткові HTTP round trips майже непомітні. У remote topology команди можуть пройти від CI runner до Selenium Server/Grid, далі до remote node або cloud browser і назад. Polling explicit waits множить network latency на кількість перевірок. Географія також впливає на system behavior: CI runner, browser node і application backend у різних регіонах дають інший latency profile, ніж локальна машина. Тому green local run не доводить, що timeout достатній для Grid/BrowserStack. Remote suite треба перевірити до merge, а browser nodes за можливості розміщувати ближче до application environment. У Playwright очікування й action orchestration потребують менше client-side polling round trips, тому modern UI suite зазвичай працює швидше й стабільніше. Але запити самої сторінки до backend однаково залежать від мережі: Playwright не прибирає latency тестованої системи.