Allure is an open-source, framework-agnostic test reporting tool that turns raw test results (XML + attachments) into a rich, interactive HTML report with steps, attachments (screenshots/videos/logs), labels (feature/story/severity), history, and custom categories. It’s commonly used with pytest + pytest-playwright to provide human-friendly reports for Playwright test runs. Allure Report

Below I’ll cover what it gives you, how it fits with Playwright+pytest, installation/commands, concrete code examples (pytest.ini, conftest.py, a sample test), and tips/troubleshooting.

1) Why use Allure with Playwright+pytest

• Beautiful, interactive HTML reports that non-dev stakeholders can read (test tree, steps, attachments, history). Allure Report

• Attach screenshots, console logs, and even recorded videos for failed tests — extremely helpful for debugging flaky UI tests. Allure Report+1

• Add metadata (feature, story, owner, severity) and custom defect categories to speed triage. Allure Report+1

---

2) What you need (short checklist)

1. pytest test runner (you probably already use it).

2. pytest-playwright (Playwright pytest plugin) for Playwright fixtures. Playwright

3. allure-pytest adapter (pip install allure-pytest) to produce Allure result files. PyPI

4. Allure Commandline (to generate/serve the HTML report). Installable via OS package managers or npm (allure-commandline) — or use Docker. Allure Reportnpm

---

5) Example: test + attaching screenshots & steps (Playwright + Allure)

import allure

def test_example(page):
    # annotate with feature/story (optional)
    allure.dynamic.feature("Home page")
    allure.dynamic.story("Title & screenshot")

    with allure.step("Open example.com"):
        page.goto("https://example.com")

    with allure.step("Check title contains Example"):
        assert "Example Domain" in page.title()

    # attach screenshot to report (bytes)
    screenshot = page.screenshot()  # returns bytes when no path given
    allure.attach(screenshot, name="homepage", attachment_type=allure.attachment_type.PNG)

• page is the Playwright fixture from pytest-playwright. Playwright

• Steps are created with allure.step (context manager/decorator) or allure.dynamic.* for labels.

Nice—I’ll assume by “@allured” and “with allured” you meant @allure.step (the decorator) vs with allure.step(...) (the context-manager). Below I explain the conceptual difference, practical trade-offs, gotchas, and give multiple real code examples you can paste into a pytest project and run.

Short summary

• @allure.step("...") — a decorator that turns a function/method into a named Allure step (great for reusable, named actions). allurereport.org

• with allure.step("..."): — a context manager that creates an inline step for the block of code that follows (great for one-off, dynamic names or grouping a code block). allurereport.org

Why the difference exists (Python basics)

Decorators wrap functions (they run code before/after a function call). Context managers create a runtime context around a block (enter/exit semantics). They are different language constructs with different use cases. The Python stdlib docs explain this pattern (ContextDecorator lets a context manager also be used like a decorator). Python documentation

Allure specifics — what each does in the report

• Both approaches create steps in the Allure report and can contain sub-steps. Use whichever fits your code structure: reusable functions → decorator; inline block → context manager. allurereport.org

• Titles / parameter interpolation: the decorator supports replacement fields tied to the decorated function’s parameter names (e.g. @allure.step("Login {username}")). The context manager lets you build a step title dynamically at runtime (e.g. with allure.step(f"Login {username}"):). allurereport.org

Gotcha / caveat

There are some edge cases reported (examples: problems when decorators use default None args in format placeholders). If you rely on field substitution in decorator titles, validate with your inputs (see a reported issue). GitHub

Also: you cannot change the step title mid-function — a decorated step’s title is determined when the step call is recorded (if you need a title that depends on values calculated inside the function, prefer the context manager or pass the values as parameters). See community discussion about dynamic step naming.

3) Combining both & showing nested steps / failure behavior

# tests/test_combined.py
import allure

@allure.step("Perform full login flow for {username}")
def perform_login(username, password):
    # decorated step will be the parent step in report
    with allure.step("Open page inside perform_login"):
        pass
    with allure.step("Fill form inside perform_login"):
        # simulate an assertion failure -> the failing step will be shown in the report
        assert password != "bad"  # if password == "bad" this sub-step fails

def test_login_flow():
    perform_login("carol", "good")      # appears as a single step with two sub-steps
    perform_login("dave", "bad")       # will mark that step (and sub-step) failed

Whether you use decorator or with, exceptions and assertion failures inside the step are captured and marked in the report — Allure will show the failing step and stack trace.

Practical guidelines — when to use each

Notes / tips

• If you use placeholders in decorator titles, ensure parameter names match exactly and watch out for weird cases (e.g. default None formatting issues reported in the Allure repo). Test the formatted title for your inputs. GitHub

• Both approaches support nesting: a decorated step can contain context steps (they become sub-steps); a context step can contain decorated steps — the hierarchy is reflected in the report. allurereport.org

• Use short descriptive step titles — Allure displays these prominently and they help triaging failures.

Fixtures

When to Use Which Scope