Збереження reports на pytest node
Зберігає reports фаз у typed pytest stash, щоб teardown fixture могла перевірити failure потрібної фази.
Після фази call item.stash[phase_reports_key]["call"] містить відповідний TestReport.
Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Зберігає reports фаз у typed pytest stash, щоб teardown fixture могла перевірити failure потрібної фази.
Після фази call item.stash[phase_reports_key]["call"] містить відповідний TestReport.
pytest hook, який формує TestReport для фаз setup, call і teardown; custom fixture може використати report для рішення про artifact retention.
У відео phase reports записуються як динамічні attributes на test node, наприклад rep_call.
Поточний official pytest example використовує typed StashKey та item.stash. Manual Playwright tracing також не записує pytest assertion як traced action; він показує browser context навколо failure.
Відкрийте implementation Locator.click() у встановленій версії Playwright.
Знайдіть frame/channel method, command name та передані options.
Запишіть, які перевірки виконує client, а які делегуються browser-side layer.
Короткий call path із назвами classes/methods і посиланням на встановлену версію package.
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`.
Чистий код важко зрозуміти лише з правил. Спочатку інженер пише прямолінійне рішення, потім стикається з duplication, coupling і складним maintenance — і лише тоді бачить, яку конкретну проблему вирішує refactoring або design pattern. Patterns і code smells не застосовуються механічно: різні правила можуть тягнути рішення в протилежні боки. Потрібен контекст, щоб вирішити, коли достатньо простого API call, а коли справді потрібні controller, DTO, serialization та додаткові abstraction layers.
Саме оголошення `def print_hello():` нічого не виконує. Функцію треба окремо викликати. Це розділяє опис поведінки та момент її запуску. Далі функція параметризується ім’ям. Замість фіксованого `Hello World` вона приймає `name` і формує `f"Hello {name}"`, тому один алгоритм працює з різними вхідними даними.