Access Test_info In Conftest.py: Pytest & Playwright

Hey everyone! Today, we're diving deep into a common challenge faced when using Pytest and Playwright together: accessing the test_info fixture within your custom fixtures in conftest.py. This can be a bit tricky, but don't worry, we'll break it down step by step so you can master it. Let's get started!

Understanding the test_info Fixture

First off, what exactly is this test_info fixture we're talking about? In Pytest, test_info is an inbuilt fixture that provides valuable information about the currently running test. This includes details like the test name, any associated markers, and crucially, the test report object. The test report object allows you to access and modify test outcomes, add attachments (like screenshots or logs), and much more. It’s an incredibly powerful tool for enhancing your testing process, especially when integrating with tools like Playwright.

When you're working with Playwright, which is a fantastic library for browser automation and end-to-end testing, the ability to access test_info becomes even more critical. Imagine you want to capture a screenshot when a test fails or add some custom logging based on the test's outcome. That's where test_info shines. By leveraging this fixture, you can create robust and informative test reports that help you quickly identify and resolve issues. Now, let's dive into the common problem: trying to access test_info in your conftest.py file and why it sometimes feels like it's playing hide-and-seek.

Why Accessing test_info in conftest.py Can Be Tricky

The main reason accessing test_info in conftest.py can be challenging is due to the way Pytest handles fixture discovery and execution. The conftest.py file is a special file that Pytest uses to load fixtures, plugins, and other configurations. Fixtures defined in conftest.py are meant to be available across multiple test files, making it a great place for setting up test environments, creating helper functions, and defining common resources.

However, the scope and timing of when these fixtures are initialized can affect whether test_info is readily available. Pytest fixtures have different scopes (function, class, module, session), and test_info is typically function-scoped, meaning it's created and available for each test function. When you try to use test_info in a fixture that has a broader scope (like session or module), it might not be initialized yet, leading to errors or unexpected behavior. This is because fixtures with broader scopes are set up before individual tests run, and test_info is specific to each test function's execution context.

Another aspect to consider is how Pytest discovers and injects fixtures. When you declare a fixture as a parameter in your test function or another fixture, Pytest automatically injects the fixture's return value. This injection process relies on Pytest's internal mechanisms, which might not always make fixtures like test_info immediately visible or accessible in all contexts, especially within conftest.py. So, how do we navigate these challenges and successfully access test_info in our custom fixtures? Let's explore some solutions.

Solutions for Accessing test_info in Custom Fixtures

Okay, let’s get to the good stuff – how to actually access test_info in your custom fixtures within conftest.py. There are a few approaches you can take, and the best one often depends on your specific use case. I will break down some common and effective strategies to solve this issue.

1. Using Function-Scoped Fixtures

The most straightforward way to access test_info is to ensure your custom fixture also has function scope. This means the fixture will be executed for each test function, ensuring test_info is available within the fixture's scope. Here's how you can do it:

import pytest

@pytest.fixture(scope="function")
def my_custom_fixture(test_info):
    print(f"Test name: {test_info.name}")
    # Your custom logic here
    yield
    # Teardown logic here

In this example, my_custom_fixture is decorated with @pytest.fixture(scope="function"), which tells Pytest to run this fixture for every test function. By including test_info as a parameter, you're telling Pytest to inject the test_info fixture into your custom fixture. Now you can access all the properties of test_info, such as test_info.name, test_info.result, and test_info.nodeid. This ensures that the test_info fixture is properly scoped and available when your custom fixture runs.

2. Passing test_info as a Parameter

Another approach is to explicitly pass test_info as a parameter to your custom fixture. This is useful when you have fixtures with broader scopes (like module or session) but still need access to test_info within them. You can achieve this by creating a function-scoped fixture that acts as a bridge.

import pytest

@pytest.fixture(scope="session")
def my_session_fixture(request):
    # This fixture has session scope
    def _finalizer():
        print("Session fixture teardown")
    request.addfinalizer(_finalizer)
    return {"some_data": "session data"}

@pytest.fixture(scope="function")
def function_scoped_bridge(test_info):
    # This fixture acts as a bridge to access test_info
    return test_info

@pytest.fixture
def my_custom_fixture(my_session_fixture, function_scoped_bridge):
    test_info = function_scoped_bridge
    print(f"Test name in custom fixture: {test_info.name}")
    session_data = my_session_fixture["some_data"]
    print(f"Session data: {session_data}")
    yield

In this example, my_session_fixture has session scope, meaning it runs once per test session. We create a function_scoped_bridge fixture that simply returns test_info. Then, in my_custom_fixture, we include both my_session_fixture and function_scoped_bridge as parameters. This allows us to access test_info via function_scoped_bridge within our custom fixture, even though it has a broader scope. This pattern is particularly useful when you need to combine session-level setup with test-specific information.

3. Using request.node to Access Test Information

In some cases, you might need to access test information outside of the test_info fixture directly. Pytest provides the request fixture, which has a node attribute that represents the test function or class currently being executed. The request.node object contains various properties, including nodeid (the unique ID of the test), name (the name of the test), and function (the actual test function object).

Here’s how you can use request.node in your custom fixture:

import pytest

@pytest.fixture
def my_custom_fixture(request):
    test_name = request.node.name
    print(f"Test name from request.node: {test_name}")
    yield

This approach is especially handy when you don’t need the full functionality of test_info but just require basic information about the test. For instance, you might use request.node.name to generate unique filenames for screenshots or logs.

4. Utilizing Pytest Hooks

Pytest hooks are powerful mechanisms that allow you to customize and extend Pytest's behavior. Hooks are functions that Pytest calls at various points during the test lifecycle. By implementing specific hooks, you can access test information and perform actions based on test outcomes. One relevant hook for our discussion is pytest_runtest_makereport.

The pytest_runtest_makereport hook is called after each test function has finished executing. It receives a pytest.TestReport object, which contains detailed information about the test result, including its status (passed, failed, skipped), any exceptions raised, and captured output. You can use this hook to access test information and perform actions such as adding attachments or custom logging.

Here’s an example of using pytest_runtest_makereport in your conftest.py file:

import pytest

@pytest.hookimpl(hookwrapper=True)
def pytest_runtest_makereport(item, call):
    outcome = yield
    report = outcome.get_result()
    if report.when == "call" and report.failed:
        print(f"Test failed: {item.nodeid}")
        # Access test information via item
        # You can also add attachments here using test_info (if available)

In this example, we use the hookwrapper=True to wrap the hook function. This allows us to execute code before and after the hook’s normal execution. We get the test report object using outcome.get_result() and check if the test failed during the “call” phase (i.e., during the test function’s execution). If it did, we print a message and can access test information via the item object, which represents the test item. This approach is particularly useful for post-test actions, such as capturing screenshots or logging additional details when a test fails.

Real-World Examples and Use Cases

Now that we've covered the solutions, let's look at some practical examples where accessing test_info can be a game-changer. These real-world scenarios will illustrate how you can leverage test_info to enhance your testing workflows.

1. Capturing Screenshots on Failure

One of the most common use cases for test_info is capturing screenshots when a test fails. This provides valuable visual evidence of the failure, making it easier to diagnose and fix issues. By accessing test_info, you can add screenshots as attachments to your test report, which can then be viewed in your CI/CD system or test reporting tool.

Here’s how you can implement this with Playwright:

import pytest
from playwright.sync_api import Page

@pytest.fixture
def page(test_info, page: Page):
    yield page
    if test_info.result() == "failed":
        screenshot_path = f"screenshots/{test_info.name}.png"
        page.screenshot(path=screenshot_path)
        test_info.attach(
            name="screenshot",
            content=open(screenshot_path, "rb").read(),
            content_type="image/png",
        )

In this example, we create a page fixture that yields a Playwright Page object. After the test runs, we check if test_info.result() is