Why advanced fixtures handle complex scenarios in PyTest - Automation Benefits in Action

Automate test setup using advanced pytest fixtures for complex scenario

Preconditions (2)

Step 1: Create an advanced fixture that sets up a database connection before tests and tears it down after tests

Step 2: Use the fixture in a test that inserts data into the database

Step 3: Verify the data insertion was successful

Step 4: Ensure the fixture handles setup and teardown only once for multiple tests

✅ Expected Result: Tests run successfully using the advanced fixture, data is inserted correctly, and setup/teardown happens only once

Automation Requirements - pytest

Assertions Needed:

Assert data inserted into database matches expected values

Assert fixture setup and teardown are called exactly once

Best Practices:

Use pytest fixtures with scope='module' or 'session' for complex setup

Use yield in fixtures to handle setup and teardown cleanly

Avoid hardcoding setup in each test, reuse fixture

Keep tests independent and idempotent

Automated Solution

PyTest

import pytest

class FakeDatabase:
    def __init__(self):
        self.data = []
        self.connected = False

    def connect(self):
        self.connected = True

    def disconnect(self):
        self.connected = False

    def insert(self, item):
        if not self.connected:
            raise Exception("Not connected")
        self.data.append(item)

    def get_all(self):
        return self.data

@pytest.fixture(scope="module")
def db():
    db_instance = FakeDatabase()
    db_instance.connect()  # Setup
    yield db_instance
    db_instance.disconnect()  # Teardown

def test_insert_data(db):
    db.insert({'id': 1, 'name': 'Test Item'})
    all_data = db.get_all()
    assert {'id': 1, 'name': 'Test Item'} in all_data

def test_insert_another_data(db):
    db.insert({'id': 2, 'name': 'Another Item'})
    all_data = db.get_all()
    assert {'id': 2, 'name': 'Another Item'} in all_data

This code defines a FakeDatabase class to simulate a database connection and data insertion.

The db fixture uses scope='module' so it sets up once per module, connecting before tests and disconnecting after all tests finish. The yield keyword separates setup and teardown.

Two tests use the db fixture to insert data and verify it was added correctly. Because the fixture is module-scoped, the database connection is reused, demonstrating how advanced fixtures handle complex setup and teardown efficiently.

Common Mistakes - 3 Pitfalls

Using function-scoped fixtures for expensive setup causing repeated setup/teardown

Not using yield in fixtures and manually calling teardown in tests

Hardcoding setup inside each test instead of using fixtures

Bonus Challenge

Now add data-driven testing with 3 different data inputs using the advanced fixture

Show Hint

Practice

1. What is the main reason to use advanced fixtures in pytest?

easy

A. To avoid writing any assertions

B. To write tests without any setup

C. To make tests run slower

D. To manage complex setup and cleanup for tests

Solution

1. Step 1: Understand the role of fixtures

   Fixtures in pytest help prepare the environment before tests run and clean up after tests finish.

2. Step 2: Identify why advanced fixtures are used

   Advanced fixtures handle more complex setup and teardown tasks, making tests clearer and more reliable.

3. Final Answer:

   To manage complex setup and cleanup for tests -> Option D

4. Quick Check:

   Advanced fixtures = manage complex setup [OK]

Hint: Fixtures handle setup and cleanup tasks [OK]

Common Mistakes:

• Thinking fixtures remove the need for assertions
• Believing fixtures slow down tests intentionally
• Assuming fixtures eliminate all test code

2. Which of the following is the correct syntax to define a fixture in pytest?

easy

A. def fixture(): pass

B. @pytest.fixture
def my_fixture(): pass

C. @fixture
def my_fixture(): pass

D. def my_fixture() @pytest.fixture: pass

Solution

1. Step 1: Recall pytest fixture syntax

   Fixtures are defined by decorating a function with @pytest.fixture.

2. Step 2: Check each option

   @pytest.fixture def my_fixture(): pass correctly uses @pytest.fixture decorator before the function definition.

3. Final Answer:

   @pytest.fixture\ndef my_fixture(): pass -> Option B

4. Quick Check:

   @pytest.fixture decorator = correct syntax [OK]

Hint: Use @pytest.fixture decorator before function [OK]

Common Mistakes:

• Forgetting the @pytest.fixture decorator
• Using @fixture without pytest prefix
• Placing decorator after function definition

3. Given the code below, what will be printed when running the test?

import pytest

@pytest.fixture
def resource():
    print('Setup resource')
    yield 'data'
    print('Cleanup resource')

def test_example(resource):
    print(f'Using {resource}')

medium

A. Setup resource\nUsing data\nCleanup resource

B. Using data\nSetup resource\nCleanup resource

C. Setup resource\nCleanup resource\nUsing data

D. Using data only

Solution

1. Step 1: Understand fixture execution order

   The fixture runs setup code before the test (prints 'Setup resource'), then yields the value.

2. Step 2: Trace test and fixture cleanup

   The test prints 'Using data'. After test finishes, fixture runs cleanup code (prints 'Cleanup resource').

3. Final Answer:

   Setup resource\nUsing data\nCleanup resource -> Option A

4. Quick Check:

   Setup -> Test -> Cleanup order = C [OK]

Hint: Fixture setup runs before test, cleanup after [OK]

Common Mistakes:

• Assuming cleanup runs before test
• Thinking yield returns after test ends
• Ignoring print order in fixture

4. Identify the error in this fixture code that causes the test to fail:

import pytest

@pytest.fixture
def setup_db():
    connection = open_db()
    return connection
    close_db(connection)

def test_query(setup_db):
    assert setup_db.is_connected()

medium

A. assert statement is incorrect

B. Fixture should not return any value

C. close_db(connection) is never called due to return before it

D. open_db() is not defined

Solution

1. Step 1: Analyze fixture return and cleanup

   The fixture returns connection before calling close_db(connection), so cleanup never runs.

2. Step 2: Understand proper cleanup in fixtures

   Cleanup code after return is unreachable; use yield to run cleanup after test.

3. Final Answer:

   close_db(connection) is never called due to return before it -> Option C

4. Quick Check:

   Return before cleanup skips cleanup [OK]

Hint: Use yield for cleanup after test, not return [OK]

Common Mistakes:

• Placing cleanup code after return statement
• Not using yield for teardown
• Assuming return runs cleanup code

5. You want to share a database connection across multiple tests but ensure it is created only once and closed after all tests finish. Which advanced fixture feature should you use?

hard

A. Use fixture with scope='module' and yield for setup and teardown

B. Use a simple function without fixture decorator

C. Create connection inside each test separately

D. Use fixture with autouse=False and no yield

Solution

1. Step 1: Understand fixture scopes

   Setting scope='module' makes fixture run once per module, sharing resource across tests.

2. Step 2: Use yield to manage setup and teardown

   Yield allows setup before tests and cleanup after all tests using the fixture.

3. Final Answer:

   Use fixture with scope='module' and yield for setup and teardown -> Option A

4. Quick Check:

   Scope='module' + yield = shared setup/cleanup [OK]

Hint: Use scope='module' and yield for shared resource cleanup [OK]

Common Mistakes:

• Creating resource in each test causing overhead
• Not using yield so cleanup never runs
• Using autouse without scope causing multiple setups