pytest-mock for enhanced mocking - Framework Patterns

Framework Mode - pytest-mock for enhanced mocking

Folder Structure

test_project/
├── tests/
│   ├── test_example.py
│   ├── test_service.py
│   └── __init__.py
├── src/
│   ├── service.py
│   └── __init__.py
├── conftest.py
├── requirements.txt
└── pytest.ini

This structure separates source code in src/ and tests in tests/. The conftest.py file holds shared fixtures and mocks setup.

Test Framework Layers

• Source Code Layer (src/): Contains application logic to be tested.
• Test Layer (tests/): Contains test cases using pytest and pytest-mock for mocking dependencies.
• Fixtures and Mocks (conftest.py): Central place for reusable pytest fixtures and mock setups using pytest-mock plugin.
• Configuration Layer (pytest.ini): Holds pytest configuration like markers and test options.
• Dependency Management (requirements.txt): Lists pytest and pytest-mock packages.

Configuration Patterns

• pytest.ini: Configure test markers, addopts for verbosity, and test paths.

  [pytest]
  addopts = -v --tb=short
  markers =
      integration: mark test as integration test
      unit: mark test as unit test
  

• conftest.py: Define fixtures for environment setup, mock objects, and shared test data.

  import pytest
  
  @pytest.fixture
  def mock_api_call(mocker):
      return mocker.patch('src.service.api_call')
  

• Environment Variables: Use os.environ or pytest plugins like pytest-env to manage credentials and environment-specific settings.

Test Reporting and CI/CD Integration

• Use pytest built-in reporting with verbose output for clear pass/fail results.
• Integrate with CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins) to run tests automatically on code push.
• Generate JUnit XML reports for CI tools to parse:

  pytest --junitxml=reports/results.xml

• Use pytest plugins like pytest-html for human-readable HTML reports.
• Fail fast option --maxfail=1 can be used to stop on first failure during CI runs.

Best Practices

1. Use pytest-mock fixture: Use the mocker fixture from pytest-mock to patch dependencies cleanly and restore them automatically after tests.
2. Isolate tests: Mock external calls and side effects to keep tests fast and reliable.
3. Centralize mocks: Define common mocks in conftest.py to avoid duplication and improve maintainability.
4. Use descriptive test names and markers: Helps organize and selectively run tests.
5. Keep tests independent: Avoid shared state between tests to prevent flaky results.

Self Check

Where in this framework structure would you add a new mock for an external API call used in multiple tests?

Key Result

Use pytest-mock's mocker fixture in conftest.py to create reusable, clean mocks for isolated and maintainable tests.

Practice

1. What is the main purpose of using pytest-mock in tests?

easy

A. To replace parts of code with mock objects during testing

B. To speed up test execution by skipping tests

C. To automatically generate test data

D. To format test output for better readability

Solution

1. Step 1: Understand pytest-mock functionality

   pytest-mock is a plugin that helps replace parts of your code with mock objects during tests.

2. Step 2: Identify the main use case

   This replacement allows you to control and verify behavior without running actual code parts.

3. Final Answer:

   To replace parts of code with mock objects during testing -> Option A

4. Quick Check:

   pytest-mock = mocking code parts [OK]

Hint: Remember pytest-mock is for replacing code parts with mocks [OK]

Common Mistakes:

• Confusing mocking with test skipping
• Thinking pytest-mock generates test data
• Assuming pytest-mock formats output

2. Which of the following is the correct way to mock a function get_data in module my_module using pytest-mock?

easy

A. mocker.patch('my_module.get_data')

B. mocker.patch(get_data)

C. mocker.mock('my_module.get_data')

D. mocker.replace('my_module.get_data')

Solution

1. Step 1: Recall pytest-mock patch syntax

   The correct syntax uses a string with the full path: mocker.patch('module.function').

2. Step 2: Identify correct option

   mocker.patch('my_module.get_data') uses the correct string path format. Options A, B, and D use incorrect methods or arguments.

3. Final Answer:

   mocker.patch('my_module.get_data') -> Option A

4. Quick Check:

   Use string path in mocker.patch() [OK]

Hint: Use string 'module.function' in mocker.patch() [OK]

Common Mistakes:

• Passing function object instead of string path
• Using mocker.mock instead of patch
• Using mocker.replace which doesn't exist

3. Given the code below, what will be the output of the test?

def fetch_data():
    return 'real data'

def test_fetch(mocker):
    mocker.patch('__main__.fetch_data', return_value='mocked data')
    result = fetch_data()
    assert result == 'mocked data'
    print(result)

medium

A. real data

B. Test fails with AssertionError

C. mocked data

D. None

Solution

1. Step 1: Understand patch effect on fetch_data

   The patch replaces fetch_data to always return 'mocked data'.

2. Step 2: Analyze test assertions and print

   The assertion checks for 'mocked data' and passes. The print outputs 'mocked data'.

3. Final Answer:

   mocked data -> Option C

4. Quick Check:

   Patched function returns mocked data [OK]

Hint: Patched functions return mocked values, not real ones [OK]

Common Mistakes:

• Expecting original function output
• Confusing patch target string
• Assuming patch does not affect print

4. Identify the error in the following test code using pytest-mock:

def test_api_call(mocker):
    mocker.patch('api.call', return_value=200)
    response = api.call()
    assert response == 200

medium

A. The return_value should be a string, not an integer

B. assert statement syntax is wrong

C. mocker.patch should be called after the function call

D. The patch target string 'api.call' is incorrect or incomplete

Solution

1. Step 1: Check patch target correctness

   The patch target 'api.call' must be the full import path. If 'api' is not imported or incomplete, patch fails.

2. Step 2: Validate other parts

   Return value as integer is valid, patch before call is correct, and assert syntax is fine.

3. Final Answer:

   The patch target string 'api.call' is incorrect or incomplete -> Option D

4. Quick Check:

   Patch target must be full import path [OK]

Hint: Always use full import path in patch target string [OK]

Common Mistakes:

• Using partial or wrong patch target strings
• Thinking return_value must be string
• Calling patch after function call

5. You want to test a function process_data() that calls fetch_from_api(). Using pytest-mock, how do you mock fetch_from_api to return different values on consecutive calls: first 'data1', then 'data2'?

hard

A. mocker.patch('module.fetch_from_api', return_value=['data1', 'data2'])

B. mocker.patch('module.fetch_from_api', side_effect=['data1', 'data2'])

C. mocker.patch('module.fetch_from_api', side_effect='data1', 'data2')

D. mocker.patch('module.fetch_from_api', return_values=['data1', 'data2'])

Solution

1. Step 1: Understand side_effect usage

   To return different values on consecutive calls, use side_effect with a list of return values.

2. Step 2: Identify correct syntax

   mocker.patch('module.fetch_from_api', side_effect=['data1', 'data2']) correctly uses side_effect=['data1', 'data2']. Options B, C, and D use incorrect parameters or syntax.

3. Final Answer:

   mocker.patch('module.fetch_from_api', side_effect=['data1', 'data2']) -> Option B

4. Quick Check:

   Use side_effect list for multiple return values [OK]

Hint: Use side_effect list to mock multiple return values [OK]

Common Mistakes:

• Using return_value with a list instead of side_effect
• Incorrect side_effect syntax with multiple arguments
• Using non-existent return_values parameter