Fixture factories in PyTest - Build an Automation Script

Automate user creation using fixture factory

Preconditions (2)

Step 1: Use the fixture factory to create a user with default attributes

Step 2: Use the fixture factory to create a user with a custom username 'testuser'

Step 3: Verify that the created user objects have the expected attributes

✅ Expected Result: The test should pass confirming that the fixture factory creates user objects correctly with default and custom attributes

Automation Requirements - pytest

Assertions Needed:

Assert default user has username 'defaultuser'

Assert custom user has username 'testuser'

Best Practices:

Use fixture factory pattern to generate test data

Keep fixtures modular and reusable

Use assert statements for validation

Avoid hardcoding test data inside tests

Automated Solution

PyTest

import pytest

class User:
    def __init__(self, username, email):
        self.username = username
        self.email = email

@pytest.fixture
def user_factory():
    def create_user(username='defaultuser', email='[e-mail]'):
        return User(username, email)
    return create_user

def test_user_creation(user_factory):
    default_user = user_factory()
    assert default_user.username == 'defaultuser'
    assert default_user.email == '[e-mail]'

    custom_user = user_factory(username='testuser', email='[e-mail]')
    assert custom_user.username == 'testuser'
    assert custom_user.email == '[e-mail]'

This test uses a fixture factory user_factory that returns a function to create User objects with default or custom attributes.

The test test_user_creation calls the factory twice: once with defaults and once with custom username and email.

Assertions check that the created users have the expected usernames and emails.

This pattern keeps test data creation flexible and reusable.

Common Mistakes - 3 Pitfalls

Defining fixture that returns a fixed user object instead of a factory function

Hardcoding user data inside the test instead of using the fixture factory

Not using assert statements to verify user attributes

Bonus Challenge

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

Show Hint

Practice

1. What is the main purpose of a fixture factory in pytest?

easy

A. To generate random test data without any input

B. To create reusable setup functions that can accept parameters

C. To run tests in parallel automatically

D. To replace the need for assertions in tests

Solution

1. Step 1: Understand what a fixture factory does

   A fixture factory is a fixture that returns a function, allowing parameter input to create varied setups.

2. Step 2: Compare options with this definition

   Only To create reusable setup functions that can accept parameters describes creating reusable setup functions that accept parameters, which matches the fixture factory concept.

3. Final Answer:

   To create reusable setup functions that can accept parameters -> Option B

4. Quick Check:

   Fixture factory = reusable setup with parameters [OK]

Hint: Fixture factories return functions to customize setup [OK]

Common Mistakes:

• Thinking fixture factories run tests in parallel
• Confusing fixture factories with random data generators
• Believing fixture factories remove the need for assertions

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

easy

A. @pytest.fixture
def data_factory():
def create_data(value):
return {'key': value}
return create_data

B. @pytest.fixture
def data_factory(value):
return {'key': value}

C. def data_factory():
return {'key': 'value'}

D. @pytest.fixture
def data_factory():
return {'key': 'value'}

Solution

1. Step 1: Identify fixture factory structure

   A fixture factory is a fixture that returns a function which accepts parameters.

2. Step 2: Check each option

   @pytest.fixture def data_factory(): def create_data(value): return {'key': value} return create_data defines a fixture returning a function that takes a parameter, matching fixture factory syntax. Others either lack the inner function or parameter handling.

3. Final Answer:

   @pytest.fixture\ndef data_factory():\n def create_data(value):\n return {'key': value}\n return create_data -> Option A

4. Quick Check:

   Fixture factory = fixture returning a function [OK]

Hint: Fixture factory returns a function inside a fixture [OK]

Common Mistakes:

• Defining fixture with parameters directly (not allowed)
• Returning data directly without inner function
• Missing @pytest.fixture decorator

3. Given the following pytest fixture factory and test, what will be the output of the assertion?

@pytest.fixture
def user_factory():
    def create_user(name):
        return {'name': name, 'active': True}
    return create_user

def test_user_active(user_factory):
    user = user_factory('Alice')
    assert user['active'] is True

medium

A. Test passes because 'active' is True

B. Test fails because 'active' key is missing

C. Test fails due to TypeError in fixture

D. Test fails because 'name' is not 'Alice'

Solution

1. Step 1: Understand fixture factory behavior

   The fixture returns a function that creates a user dict with 'name' and 'active' set to True.

2. Step 2: Analyze the test

   The test calls user_factory('Alice'), getting {'name': 'Alice', 'active': True}, then asserts user['active'] is True, which is correct.

3. Final Answer:

   Test passes because 'active' is True -> Option A

4. Quick Check:

   user['active'] = True, assertion passes [OK]

Hint: Check returned dict keys and values carefully [OK]

Common Mistakes:

• Assuming 'active' key is missing
• Confusing fixture factory return with direct dict
• Thinking 'name' must be 'Bob' instead of 'Alice'

4. Identify the error in the following fixture factory code:

@pytest.fixture
def product_factory():
    def create_product(name, price):
        return {'name': name, 'price': price}
    return create_product

def test_product(product_factory):
    product = product_factory('Book')
    assert product['price'] > 0

medium

A. Incorrect return statement in fixture factory

B. Fixture factory missing @pytest.fixture decorator

C. Missing price argument when calling product_factory in test

D. Assertion compares string to integer

Solution

1. Step 1: Check fixture factory parameters

   The inner function create_product requires two parameters: name and price.

2. Step 2: Check test call to fixture factory

   The test calls product_factory('Book') with only one argument, missing price, causing a TypeError.

3. Final Answer:

   Missing price argument when calling product_factory in test -> Option C

4. Quick Check:

   Function call missing required argument [OK]

Hint: Match all required parameters when calling fixture factory [OK]

Common Mistakes:

• Forgetting to pass all parameters to inner function
• Assuming fixture factory itself takes parameters
• Ignoring error messages about missing arguments

5. You want to test a function that processes orders with different quantities and prices. How can you use a fixture factory to create varied order data for multiple tests efficiently?

hard

A. Hardcode order data inside each test function

B. Write separate fixtures for each order variation without parameters

C. Use a global variable to store order data and modify it in tests

D. Create a fixture factory that returns a function accepting quantity and price, returning an order dict

Solution

1. Step 1: Understand the need for varied test data

   Testing different quantities and prices requires flexible data creation without repeating code.

2. Step 2: Apply fixture factory concept

   A fixture factory returning a function that accepts quantity and price allows creating varied order dicts efficiently.

3. Final Answer:

   Create a fixture factory that returns a function accepting quantity and price, returning an order dict -> Option D

4. Quick Check:

   Fixture factory = flexible, reusable test data creator [OK]

Hint: Use fixture factory to pass parameters for varied data [OK]

Common Mistakes:

• Writing many similar fixtures instead of one factory
• Using global variables causing test interference
• Hardcoding data reduces test flexibility and reuse