Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Оберіть один production defect і назвіть observable risk.
Порівняйте unit/component, API/integration та system E2E seams.
Залиште найнижчий рівень, який справді відтворює failure, і поясніть відкинуті варіанти.
Коротке рішення з failure evidence, selected seam і trade-offs.
Для одного POST endpoint опишіть immediate response assertion і спосіб перевірки eventual result.
Додайте resource-schema assertions і один business-flow assertion.
Позначте, який тест локалізує кожен failure.
Таблиця з чотирма checks, test level і failure signal.
Вибрати один user flow і намалювати client, gateway, services, databases і brokers.
Позначити synchronous і asynchronous contracts, state setup і failure boundaries.
Для кожної boundary записати одну contract check і одну end-to-end check.
Одна діаграма, за якою видно, де готувати data і як локалізувати test failure.
Через custom fixture architecture у відео вручну інтегровано tracing і pytest hook.
Поточний pytest-playwright plugin підтримує --tracing retain-on-failure. Якщо тест використовує стандартні plugin fixtures, спершу варто перевірити цю option; custom hook потрібен, коли lifecycle контролюється власними fixtures.
Пояснює, чому browser load event не дорівнює готовності application і як діагностувати hydration failure.
Що має описувати isLoaded → Першоджерело ↗Читабельний identifier конкретного parameter set, заданий через ids, callable або pytest.param(..., id=...). Він з'являється у collection і failure output.
2. Pytest fixtures, playwright fixture, прараметризація тестів →Один locator навмисно змінюється на неправильний. Тест падає, з’являється ZIP із назвою тесту, а Trace Viewer показує останній успішний крок і assertion, який не знайшов очікуваний елемент. Після доказу failure path тимчасову помилку треба прибрати й повернути suite у green state. Завершена зміна комітиться в окремій гілці; у командній роботі вона проходить pull request, а не пряме злиття без review.
Fixture не знає результат тесту напряму, тому `conftest.py` підключає hook `pytest_runtest_makereport`. Hook отримує звіт для кожної фази та записує його в атрибут node, наприклад `rep_setup`, `rep_call`, `rep_teardown`. Для assertion failure самого тесту перевіряється `request.node.rep_call.failed`. `setup` охоплює код до `yield`, `call` — тіло тесту, `teardown` — код після `yield`. Якщо потрібно зберігати trace також при fixture setup failure, це окреме розширення контракту; демонстрація фокусується на `call`.
`getByRole` спирається на роль і accessible name з accessibility tree. Інші user-facing locators — `getByLabel`, `getByText`, `getByPlaceholder`, `getByAltText` і `getByTitle` — шукають за відповідним видимим або описовим значенням. Усі вони читаються ближче до наміру користувача й роблять failure зрозумілішим для розробників — основної аудиторії результатів автотестів. Незначна різниця в швидкості locator неважлива порівняно з network та application latency.
У `try` розміщують лише операцію, яка очікувано може впасти, а `except ValueError` обробляє конкретний failure type. Широке `except Exception: pass` стирає сигнал і ускладнює debugging. Selenium, filesystem, network і parsing мають різні exception classes, які слід розрізняти.
У динамічному UI HTML може вже існувати, але продукти, кошик або кнопка checkout ще не готові. Тест, який одразу клікає елемент, отримує flaky failure: дія сталася раніше, ніж сторінка могла її обробити. Надійний readiness contract чекає, що blocking preloader зник, skeleton замінився реальним контентом, а ключовий елемент став видимим або доступним для дії.
Якщо UI price або status code неможливо перетворити на число, тест може підняти `AssertionError("Status code must be numeric") from error`. Так повідомлення пояснює бізнес-очікування, а exception chaining зберігає первинний `ValueError` і stack trace.
У `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 для кожного успішного тесту, бо архіви можуть швидко зайняти багато місця.
У моноліті business logic, email, SMS, persistence та integrations розгортаються як один application. Це не є автоматично погано: добре структурований моноліт простіший у розробці і не платить network latency за кожен внутрішній виклик. Модульний моноліт розділяє functionality всередині одного deployment і може зберігати окремі data boundaries. Мікросервісна архітектура виносить ці частини у незалежні services, але додає HTTP, serialization, handshakes, deployment і distributed failure modes.
`else` після `try/except` виконується лише коли exception не було; `finally` — завжди. Custom exception доречний, коли domain-specific failure повторюється й потребує власного змісту. Обробка має або відновити коректний стан, або завершити тест із точним сигналом — не просто продовжити виконання після невідомої помилки.
Fix комітиться й повторно запускається в pull request. Linter і smoke можуть стартувати паралельно, щоб базова функціональна перевірка не чекала на завершення статичного аналізу; точна залежність між jobs визначається вимогами проєкту. Після оновлення п’ять smoke tests проходять. Практичний цикл завершено повним ланцюжком: CI failure → artifact → локальний Trace Viewer → вузька зміна → повторний зелений smoke run.