Handling shared resources in PyTest - Build an Automation Script

Test shared resource access with setup and teardown

Preconditions (2)

Step 1: Before tests, create or clear the file 'shared_resource.txt'

Step 2: Test 1: Write 'Test1' to the file

Step 3: Verify the file contains 'Test1'

Step 4: Test 2: Append 'Test2' to the file

Step 5: Verify the file contains both 'Test1' and 'Test2' in order

Step 6: After tests, delete the file 'shared_resource.txt'

✅ Expected Result: Both tests pass, confirming that the shared resource is properly handled with setup and teardown to avoid test interference.

Automation Requirements - pytest

Assertions Needed:

Verify file content after each test matches expected text

Best Practices:

Use pytest fixtures with scope='module' or 'function' to setup and teardown shared resources

Avoid test interference by cleaning or resetting shared resources before each test

Use explicit file open modes to control write/append behavior

Automated Solution

PyTest

import os
import pytest

@pytest.fixture(scope='module')
def shared_file():
    filename = 'shared_resource.txt'
    # Setup: create or clear the file before tests
    with open(filename, 'w') as f:
        f.write('')
    yield filename
    # Teardown: remove the file after tests
    if os.path.exists(filename):
        os.remove(filename)


def test_write_test1(shared_file):
    with open(shared_file, 'w') as f:
        f.write('Test1')
    with open(shared_file, 'r') as f:
        content = f.read()
    assert content == 'Test1', f"Expected 'Test1' but got '{content}'"


def test_append_test2(shared_file):
    with open(shared_file, 'a') as f:
        f.write('Test2')
    with open(shared_file, 'r') as f:
        content = f.read()
    assert content == 'Test1Test2', f"Expected 'Test1Test2' but got '{content}'"

This code uses a pytest fixture named shared_file with scope='module' to setup and teardown a shared file resource.

Before any tests run, the fixture creates or clears the file shared_resource.txt. After all tests in the module finish, it deletes the file to clean up.

The first test writes 'Test1' to the file and verifies the content exactly matches 'Test1'.

The second test appends 'Test2' to the same file and verifies the content is 'Test1Test2', confirming the append worked and the shared resource was handled correctly.

This approach avoids interference by ensuring the file starts empty before tests and is removed after, following best practices for shared resource handling.

Common Mistakes - 4 Pitfalls

Not cleaning the shared resource before tests

Using global variables to share resource state

Not deleting or cleaning up the shared resource after tests

{'mistake': "Opening files in wrong mode (e.g., always 'w' instead of 'a' for append)", 'why_bad': 'Data can be overwritten unintentionally, causing test failures.', 'correct_approach': "Use correct file modes ('w' for write, 'a' for append) depending on test needs."}

Bonus Challenge

Now add data-driven testing with 3 different strings to write and append to the shared file

Show Hint

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