Handling shared resources in PyTest - Framework Patterns

Framework Mode - Handling shared resources

Folder Structure

tests/
├── test_login.py
├── test_shopping_cart.py
├── test_checkout.py
conftest.py
utils/
├── db_helper.py
├── api_client.py
pytest.ini
requirements.txt

Test Framework Layers

• Fixtures Layer: Defined in conftest.py to setup and teardown shared resources like database connections, test data, or web drivers.
• Tests Layer: Test files inside tests/ folder use fixtures to access shared resources safely.
• Utilities Layer: Helper modules in utils/ provide reusable functions for resource management, e.g., database queries or API calls.
• Configuration Layer: pytest.ini and environment variables control test settings and resource parameters.

Configuration Patterns

• Use pytest.ini to define default test options and markers.
• Use environment variables or .env files to store sensitive data like credentials or URLs.
• Define fixtures in conftest.py that read configuration and initialize shared resources once per session or module.
• Example: a database connection fixture with scope="session" to share the connection across all tests safely.

Test Reporting and CI/CD Integration

• Use pytest built-in reporting with options like --junitxml=report.xml for CI systems.
• Integrate with CI tools (GitHub Actions, Jenkins) to run tests on every push or pull request.
• Ensure shared resources are properly cleaned up after tests to avoid side effects in CI runs.
• Use plugins like pytest-html for readable HTML reports.

Best Practices

1. Use fixtures with appropriate scope: session, module, or function to control resource lifetime.
2. Isolate tests: Avoid tests changing shared resources in ways that affect others.
3. Cleanup resources: Use finalizers or yield fixtures to release resources after use.
4. Parameterize fixtures: To handle different configurations or environments easily.
5. Keep fixtures simple and reusable: Avoid complex logic inside fixtures to maintain clarity.

Self Check

Where in this framework structure would you add a new fixture to manage a shared API client used by multiple tests?

Key Result

Use pytest fixtures in conftest.py to manage shared resources with proper scope and cleanup.

Practice

1. What is the main purpose of using shared resources in pytest tests?

easy

A. To make tests run slower by adding extra steps

B. To reuse setup work and avoid conflicts between tests

C. To write tests without any setup or teardown

D. To skip tests that use external files

Solution

1. Step 1: Understand shared resources in testing

   Shared resources allow multiple tests to use the same setup, saving time and avoiding repeated work.

2. Step 2: Recognize the benefit of avoiding conflicts

   Using shared resources carefully prevents tests from interfering with each other, keeping results reliable.

3. Final Answer:

   To reuse setup work and avoid conflicts between tests -> Option B

4. Quick Check:

   Shared resources = reuse setup + avoid conflicts [OK]

Hint: Shared resources save setup time and prevent test clashes [OK]

Common Mistakes:

• Thinking shared resources slow tests down
• Believing shared resources remove the need for setup
• Confusing shared resources with skipping tests

2. Which pytest fixture scope is best to share a resource across all tests in a module?

easy

A. "function" scope

B. "class" scope

C. "session" scope

D. "module" scope

Solution

1. Step 1: Recall pytest fixture scopes

   "function" runs for each test, "class" for each test class, "module" for all tests in a file, "session" for all tests in a run.

2. Step 2: Identify scope for sharing in a module

   To share a resource across all tests in one module (file), use "module" scope.

3. Final Answer:

   "module" scope -> Option D

4. Quick Check:

   Module scope = share resource in one file [OK]

Hint: "module" scope shares resource across one test file [OK]

Common Mistakes:

• Using "function" scope which creates resource per test
• Choosing "class" scope which limits sharing to test classes
• Confusing "session" scope which shares across all tests

3. What will be the output of this pytest fixture usage?

import pytest

@pytest.fixture(scope="module")
def resource():
    print("Setup resource")
    yield "data"
    print("Teardown resource")

def test_one(resource):
    assert resource == "data"

def test_two(resource):
    assert resource == "data"

medium

A. Setup resource printed once, then tests pass, then Teardown resource printed once

B. Setup resource and Teardown resource printed before each test

C. Setup resource printed twice, no teardown printed

D. No output printed because print statements are ignored

Solution

1. Step 1: Understand fixture scope and yield behavior

   With "module" scope, setup runs once before all tests in the module, yield provides the resource, and teardown runs once after all tests.

2. Step 2: Analyze print outputs during test run

   "Setup resource" prints once before tests, both tests use the resource and pass, then "Teardown resource" prints once after all tests.

3. Final Answer:

   Setup resource printed once, then tests pass, then Teardown resource printed once -> Option A

4. Quick Check:

   Module scope fixture setup/teardown run once [OK]

Hint: Module scope fixture setup/teardown run once per module [OK]

Common Mistakes:

• Expecting setup/teardown to run before and after each test
• Thinking print statements are suppressed
• Confusing fixture scope with function scope

4. Identify the error in this pytest fixture that shares a database connection:

@pytest.fixture(scope="module")
def db_connection():
    conn = open_db()
    yield conn
    conn.close()

def test_query(db_connection):
    assert db_connection.execute("SELECT 1") == 1

def test_insert(db_connection):
    db_connection.execute("INSERT INTO table VALUES (1)")

medium

A. The connection might be shared but not reset between tests causing side effects

B. The fixture does not close the connection after tests

C. The fixture scope should be "function" to avoid conflicts

D. The yield statement is missing in the fixture

Solution

1. Step 1: Review fixture setup and teardown

   The fixture opens a connection, yields it, then closes it after all tests in the module.

2. Step 2: Consider side effects of shared connection

   Because the connection is shared and not reset between tests, changes in one test (like insert) may affect others, causing flaky tests.

3. Final Answer:

   The connection might be shared but not reset between tests causing side effects -> Option A

4. Quick Check:

   Shared resource without reset risks test interference [OK]

Hint: Shared resources need reset or isolation to avoid side effects [OK]

Common Mistakes:

• Thinking connection is never closed
• Assuming function scope is always required
• Missing yield statement in fixture

5. You want to share a temporary folder between tests but ensure it is empty before each test. Which pytest fixture setup is best?

hard

A. Use a "module" scoped fixture that creates the folder once and clears it before each test

B. Use a "session" scoped fixture that creates the folder once and never cleans it

C. Use a "function" scoped fixture that creates and deletes the folder for each test

D. Use a "class" scoped fixture that creates the folder once per test class without cleanup

Solution

1. Step 1: Understand the need to share and clean resource

   You want to share the folder to save setup time but also ensure it is empty before each test to avoid leftover files.

2. Step 2: Choose fixture scope and cleanup strategy

   A "function" scoped fixture creates and deletes the folder for each test, ensuring it is empty before each test and avoiding leftover files.

3. Final Answer:

   Use a "function" scoped fixture that creates and deletes the folder for each test -> Option C

4. Quick Check:

   Function scope fixture creates clean folder per test [OK]

Hint: Create and delete resource per test for clean state [OK]

Common Mistakes:

• Using function scope causing slow tests
• Using session scope without cleanup causing test pollution
• Using class scope which limits sharing incorrectly