← Python

Testing (unittest, pytest, mocking)

← Testing (unittest, pytest, mocking)

Select a question from the sidebar

12 questions in this topic

Question 1 / 12

What are the key differences between unittest and pytest?

Both are Python testing frameworks, but they differ significantly in philosophy and syntax:

unittest (standard library)

Class-based: tests must be methods in a TestCase subclass
Uses self.assertEqual(), self.assertRaises(), etc.
setUp/tearDown for fixtures
Verbose, Java-like style
Built into Python, no extra install

pytest (third-party)

Function-based: plain functions with assert statements
Automatic test discovery (files/functions starting with test_)
Rich fixture system with dependency injection
Powerful parametrize for data-driven tests
Better error messages (assertion introspection)
Huge plugin ecosystem
Can run unittest tests too

When to use which:

pytest: Almost always preferred for new projects
unittest: Legacy codebases, or when you cannot install third-party packages

Pseudo Code

unittest style:
  class TestMath(TestCase):
      def test_add(self):
          self.assertEqual(add(1, 2), 3)

pytest style:
  def test_add():
      assert add(1, 2) == 3

Code

# unittest style
import unittest

class TestCalculator(unittest.TestCase):
    def setUp(self):
        self.calc = Calculator()

    def test_add(self):
        self.assertEqual(self.calc.add(1, 2), 3)

    def test_divide_by_zero(self):
        with self.assertRaises(ZeroDivisionError):
            self.calc.divide(1, 0)

    def tearDown(self):
        del self.calc

# pytest style (equivalent, much simpler)
class Calculator:
    def add(self, a, b):
        return a + b
    def divide(self, a, b):
        return a / b

import pytest

def test_add():
    calc = Calculator()
    assert calc.add(1, 2) == 3

def test_divide_by_zero():
    calc = Calculator()
    with pytest.raises(ZeroDivisionError):
        calc.divide(1, 0)

# pytest with fixtures (dependency injection)
@pytest.fixture
def calc():
    return Calculator()

def test_add_with_fixture(calc):
    assert calc.add(1, 2) == 3

# pytest parametrize (data-driven tests)
@pytest.mark.parametrize("a,b,expected", [
    (1, 2, 3),
    (0, 0, 0),
    (-1, 1, 0),
    (100, 200, 300),
])
def test_add_parametrized(calc, a, b, expected):
    assert calc.add(a, b) == expected

# pytest better error messages
def test_list_comparison():
    result = [1, 2, 3, 4]
    expected = [1, 2, 5, 4]
    assert result == expected
    # pytest shows: [1, 2, 3, 4] != [1, 2, 5, 4]
    #               At index 2: 3 != 5

Key Points

•pytest uses plain assert statements; unittest uses self.assert* methods
•pytest fixtures provide dependency injection; unittest uses setUp/tearDown
•pytest has parametrize for data-driven tests out of the box
•pytest can run unittest tests, providing an easy migration path

Gotchas

•pytest must be installed (pip install pytest); unittest is built-in
•unittest requires test classes; pytest allows plain functions (simpler)
•Mixing pytest fixtures with unittest TestCase classes has limitations
•pytest's assert rewriting does not work inside helper functions by default (use pytest.register_assert_rewrite)

unittest: class-based, self.assertEqual(), built-in. pytest: function-based, plain assert, fixtures, parametrize, better errors. Prefer pytest for new projects.

•pytest: simpler syntax, fixtures, parametrize
•unittest: built-in, class-based, verbose

# unittest
import unittest
class TestAdd(unittest.TestCase):
    def test_add(self):
        self.assertEqual(1 + 2, 3)

# pytest (simpler)
def test_add():
    assert 1 + 2 == 3

pytest needs pip install; unittest is in stdlib

Question 2 / 12

How do pytest fixtures work and what are their scopes?

Pytest fixtures provide dependency injection for test functions. A fixture is a function decorated with @pytest.fixture that provides data, objects, or services to tests that request it by name.

Scopes (lifecycle of the fixture):

function (default): Created fresh for each test function
class: Created once per test class
module: Created once per test module (.py file)
package: Created once per test package
session: Created once for the entire test session

Key features:

Dependency injection: Tests request fixtures by parameter name
Teardown: Use yield to define cleanup code
Composition: Fixtures can depend on other fixtures
autouse: Automatically applied to all tests without explicit request
conftest.py: Shared fixtures available to all tests in the directory

Pseudo Code

@pytest.fixture(scope='function')  # recreated per test
def db_connection():
    conn = create_connection()
    yield conn        # test runs here
    conn.close()      # teardown after test

def test_query(db_connection):  # fixture injected by name
    result = db_connection.execute('SELECT 1')
    assert result == 1

Code

import pytest

# Basic fixture with teardown
@pytest.fixture
def temp_list():
    data = [1, 2, 3]
    yield data  # test uses this
    data.clear()  # cleanup after test

def test_append(temp_list):
    temp_list.append(4)
    assert len(temp_list) == 4

# Fixture with scope
@pytest.fixture(scope='module')
def expensive_resource():
    print("\nCreating expensive resource (once per module)")
    resource = {"data": "loaded"}
    yield resource
    print("Cleaning up expensive resource")

def test_use_resource_1(expensive_resource):
    assert expensive_resource["data"] == "loaded"

def test_use_resource_2(expensive_resource):
    assert "data" in expensive_resource
# Both tests share the same resource instance

# Fixture composition (fixtures using other fixtures)
@pytest.fixture
def base_config():
    return {"debug": False, "db": "sqlite"}

@pytest.fixture
def app(base_config):
    base_config["initialized"] = True
    return base_config

def test_app_initialized(app):
    assert app["initialized"] is True
    assert app["db"] == "sqlite"

# Parametrized fixtures
@pytest.fixture(params=["sqlite", "postgres", "mysql"])
def db_engine(request):
    engine = f"engine:{request.param}"
    yield engine

def test_db_connection(db_engine):
    assert db_engine.startswith("engine:")
# This test runs 3 times, once for each param!

# autouse fixture (applied automatically)
@pytest.fixture(autouse=True)
def reset_environment():
    # setup
    import os
    original = os.environ.get('TEST_MODE')
    os.environ['TEST_MODE'] = '1'
    yield
    # teardown
    if original is None:
        os.environ.pop('TEST_MODE', None)
    else:
        os.environ['TEST_MODE'] = original

# conftest.py example (shared fixtures)
# In conftest.py:
# @pytest.fixture
# def auth_headers():
#     return {"Authorization": "Bearer test-token"}
# Available to ALL tests in the same directory and subdirectories

Key Points

•Fixtures provide dependency injection -- tests request by parameter name
•yield separates setup from teardown; teardown runs even on test failure
•Scope controls lifetime: function (default), class, module, session
•conftest.py shares fixtures across multiple test files

Gotchas

•Session-scoped fixtures cannot depend on function-scoped fixtures (broader cannot depend on narrower)
•autouse fixtures run for EVERY test in scope, which can cause unexpected side effects
•Fixture names must be unique within scope -- name collisions can be confusing
•yield fixtures with scope='session' run teardown only after ALL tests complete

Fixtures are @pytest.fixture functions that inject dependencies into tests by name. Use yield for setup/teardown. Scopes: function (default), class, module, session. Share via conftest.py.

•Dependency injection by parameter name
•yield for setup/teardown, conftest.py for sharing

import pytest

@pytest.fixture
def user():
    u = {"name": "Alice"}
    yield u
    u.clear()  # teardown

def test_user_name(user):  # fixture injected by name
    assert user["name"] == "Alice"

Broader scope fixtures cannot depend on narrower scope ones

Question 3 / 12

How does pytest.mark.parametrize work for data-driven testing?

@pytest.mark.parametrize runs the same test function with different input data, generating a separate test case for each set of parameters. This eliminates copy-paste of similar tests.

Syntax:

@pytest.mark.parametrize("param_names", [
    (value1_a, value1_b),
    (value2_a, value2_b),
])
def test_something(param_names):

Features:

Multiple parameters as comma-separated string or list
IDs for readable test names
Can stack multiple parametrize decorators (creates Cartesian product)
Works with fixtures
pytest.param() for per-case marks (skip, xfail)

Pseudo Code

@parametrize("input,expected", [(1, 2), (2, 4), (3, 6)])
def test_double(input, expected):
    assert double(input) == expected

# Generates 3 tests:
#   test_double[1-2]
#   test_double[2-4]
#   test_double[3-6]

Code

import pytest

# Basic parametrize
@pytest.mark.parametrize("input_val,expected", [
    (1, 1),
    (2, 4),
    (3, 9),
    (4, 16),
    (-1, 1),
    (0, 0),
])
def test_square(input_val, expected):
    assert input_val ** 2 == expected

# With custom IDs for readable output
@pytest.mark.parametrize("word,expected", [
    ("hello", 5),
    ("", 0),
    ("a", 1),
    ("hello world", 11),
], ids=["normal", "empty", "single_char", "with_space"])
def test_string_length(word, expected):
    assert len(word) == expected

# Using pytest.param for marks
@pytest.mark.parametrize("n,expected", [
    (1, 1),
    (2, 2),
    pytest.param(0, 0, marks=pytest.mark.skip(reason="edge case")),
    pytest.param(-1, 1, marks=pytest.mark.xfail(reason="negative not supported")),
])
def test_abs(n, expected):
    assert abs(n) == expected

# Stacking parametrize (Cartesian product)
@pytest.mark.parametrize("x", [1, 2, 3])
@pytest.mark.parametrize("y", [10, 20])
def test_multiply(x, y):
    result = x * y
    assert result == x * y
# Generates 6 tests: (1,10), (1,20), (2,10), (2,20), (3,10), (3,20)

# Parametrize with fixtures
@pytest.fixture
def calculator():
    class Calc:
        def add(self, a, b): return a + b
    return Calc()

@pytest.mark.parametrize("a,b,expected", [
    (1, 2, 3),
    (0, 0, 0),
    (-1, 1, 0),
])
def test_calc_add(calculator, a, b, expected):
    assert calculator.add(a, b) == expected

# Indirect parametrize (parametrize a fixture)
@pytest.fixture
def user(request):
    users = {
        "admin": {"name": "Admin", "role": "admin"},
        "guest": {"name": "Guest", "role": "guest"},
    }
    return users[request.param]

@pytest.mark.parametrize("user", ["admin", "guest"], indirect=True)
def test_user_has_role(user):
    assert "role" in user

Key Points

•Generates separate test cases from a list of parameter sets
•Custom IDs make test output readable
•Stacking @parametrize creates Cartesian product of parameters
•pytest.param() allows per-case skip/xfail marks

Gotchas

•Parameter names as a comma-separated string must match function parameter names exactly
•Stacking multiple @parametrize decorators creates multiplicative test cases (can explode)
•indirect=True passes the parameter to the fixture, not directly to the test
•Large parametrize lists should be extracted to module-level variables for readability

@pytest.mark.parametrize("params", [...]) runs the same test with different data, generating separate test cases. Stack decorators for Cartesian product.

•Each parameter set generates a separate test case
•pytest.param() for per-case marks

import pytest

@pytest.mark.parametrize("n,expected", [
    (1, 1), (2, 4), (3, 9),
])
def test_square(n, expected):
    assert n ** 2 == expected
# Generates 3 separate tests

Stacking creates multiplicative test count

Question 4 / 12

What is conftest.py and how does pytest use it?

conftest.py is a special file recognized by pytest for sharing fixtures, hooks, and configuration across multiple test files. It is automatically loaded by pytest -- no import needed.

What goes in conftest.py:

Fixtures: Shared test fixtures available to all tests in the directory and subdirectories
Hooks: Custom pytest hooks (e.g., pytest_collection_modifyitems)
Plugins: Local plugin registration
Command-line options: Custom options via pytest_addoption

Scope rules:

conftest.py in the root test directory: available to ALL tests
conftest.py in a subdirectory: available only to tests in that directory and below
Multiple conftest.py files can exist at different levels
Fixtures in closer conftest.py override those in parent directories

Pseudo Code

tests/
  conftest.py          <- fixtures available to all tests
  test_api/
    conftest.py        <- fixtures for API tests only
    test_users.py
    test_products.py
  test_models/
    conftest.py        <- fixtures for model tests only
    test_user_model.py

Code

# tests/conftest.py -- root level, available everywhere
import pytest

@pytest.fixture(scope='session')
def app():
    """Create application for testing."""
    from myapp import create_app
    app = create_app({'TESTING': True})
    yield app

@pytest.fixture(scope='session')
def db(app):
    """Set up test database."""
    from myapp.extensions import db as _db
    with app.app_context():
        _db.create_all()
        yield _db
        _db.drop_all()

@pytest.fixture
def client(app):
    """Test client for HTTP requests."""
    return app.test_client()

@pytest.fixture
def auth_headers():
    """Authentication headers for API tests."""
    return {'Authorization': 'Bearer test-token-123'}

# Custom command-line option
def pytest_addoption(parser):
    parser.addoption(
        '--slow', action='store_true', default=False,
        help='Run slow tests'
    )

# Custom hook: skip slow tests unless --slow flag
def pytest_collection_modifyitems(config, items):
    if not config.getoption('--slow'):
        skip_slow = pytest.mark.skip(reason='Need --slow option to run')
        for item in items:
            if 'slow' in item.keywords:
                item.add_marker(skip_slow)

# tests/test_api/conftest.py -- API-specific fixtures
@pytest.fixture
def sample_user(db):
    """Create a sample user for API tests."""
    user = {'id': 1, 'name': 'Test User', 'email': 'test@example.com'}
    # In real code: user = User.create(**user)
    yield user
    # Cleanup

@pytest.fixture
def api_client(client, auth_headers):
    """Client with auth headers pre-configured."""
    class AuthClient:
        def __init__(self, client, headers):
            self._client = client
            self._headers = headers
        def get(self, url, **kwargs):
            kwargs.setdefault('headers', self._headers)
            return self._client.get(url, **kwargs)
        def post(self, url, **kwargs):
            kwargs.setdefault('headers', self._headers)
            return self._client.post(url, **kwargs)
    return AuthClient(client, auth_headers)

# tests/test_api/test_users.py -- uses fixtures from both conftest.py files
def test_get_user(api_client, sample_user):
    response = api_client.get(f"/api/users/{sample_user['id']}")
    assert response.status_code == 200

@pytest.mark.slow
def test_bulk_import(api_client):
    # Only runs with pytest --slow
    pass

Key Points

•conftest.py is auto-loaded by pytest -- no imports needed
•Fixtures defined there are available to all tests in same directory and below
•Multiple conftest.py at different levels for scoped sharing
•Also used for hooks, plugins, and custom CLI options

Gotchas

•conftest.py must NOT be imported manually -- pytest handles loading
•Fixtures in child conftest.py override parent fixtures of the same name
•conftest.py is not a place for test functions -- only fixtures and configuration
•Heavy session-scoped fixtures in conftest.py slow down initial test startup

conftest.py is auto-loaded by pytest to share fixtures, hooks, and configuration. Fixtures there are available to all tests in the same directory and subdirectories. No import needed.

•Auto-loaded, no imports needed
•Scoped by directory hierarchy

# conftest.py
import pytest

@pytest.fixture
def db():
    conn = create_connection()
    yield conn
    conn.close()

# test_something.py (no import needed!)
def test_query(db):  # fixture from conftest.py
    assert db.execute('SELECT 1')

Never import conftest.py manually

Question 5 / 12

How do you use unittest.mock.patch and MagicMock for mocking?

The unittest.mock module provides tools to replace parts of your system with mock objects during testing.

Key classes:

Mock(): Base mock object, returns new Mock for any attribute/call
MagicMock(): Mock with default implementations of magic methods (__len__, __iter__, etc.)
patch(): Context manager/decorator that temporarily replaces an object
patch.object(): Patches a specific attribute on an object

The `patch` rule:

Patch where the object is USED, not where it is DEFINED. If module_a.py imports requests.get, patch module_a.requests.get, not requests.get.

Assertions on mocks:

mock.assert_called_once()
mock.assert_called_with(*args, **kwargs)
mock.assert_called_once_with(*args, **kwargs)
mock.call_count
mock.call_args / mock.call_args_list

Pseudo Code

Patch rule:
  # mymodule.py imports requests
  import requests
  def fetch(url): return requests.get(url)

  # test: patch where it's used
  @patch('mymodule.requests.get')  # NOT 'requests.get'
  def test_fetch(mock_get):
      mock_get.return_value.status_code = 200
      result = fetch('http://example.com')
      mock_get.assert_called_once()

Code

from unittest.mock import Mock, MagicMock, patch, call

# Basic Mock
mock = Mock()
mock.some_method.return_value = 42
print(mock.some_method())  # 42
mock.some_method.assert_called_once()

# MagicMock (supports magic methods)
mm = MagicMock()
mm.__len__.return_value = 5
print(len(mm))  # 5
mm.__getitem__.return_value = 'value'
print(mm[0])  # 'value'

# Mock with side_effect
mock = Mock()
mock.side_effect = [1, 2, 3]  # return values in sequence
print(mock(), mock(), mock())  # 1 2 3

mock.side_effect = ValueError("boom")  # raise exception
try:
    mock()
except ValueError as e:
    print(f"Caught: {e}")

mock.side_effect = lambda x: x * 2  # custom function
print(mock(5))  # 10

# patch as decorator
class UserService:
    def __init__(self, db):
        self.db = db

    def get_user(self, user_id):
        return self.db.query(f"SELECT * FROM users WHERE id={user_id}")

# Simulating the module structure
import types
user_module = types.ModuleType('user_module')
user_module.UserService = UserService

# patch as context manager
def test_with_context_manager():
    mock_db = Mock()
    mock_db.query.return_value = {"id": 1, "name": "Alice"}

    service = UserService(mock_db)
    result = service.get_user(1)

    assert result == {"id": 1, "name": "Alice"}
    mock_db.query.assert_called_once()
    print(f"Called with: {mock_db.query.call_args}")

test_with_context_manager()

# patch.object for specific attributes
class EmailService:
    def send(self, to, subject, body):
        # Actually sends email
        pass

    def send_welcome(self, user):
        self.send(user['email'], 'Welcome!', f'Hi {user["name"]}')

def test_send_welcome():
    service = EmailService()
    with patch.object(service, 'send') as mock_send:
        service.send_welcome({'name': 'Bob', 'email': 'bob@test.com'})
        mock_send.assert_called_once_with(
            'bob@test.com', 'Welcome!', 'Hi Bob'
        )

test_send_welcome()

# Verifying call arguments
mock = Mock()
mock(1, 2, key='value')
mock(3, 4)

assert mock.call_count == 2
assert mock.call_args_list == [
    call(1, 2, key='value'),
    call(3, 4)
]
assert mock.call_args == call(3, 4)  # last call

# spec: restrict mock to real object's interface
class RealAPI:
    def get(self, url): pass
    def post(self, url, data): pass

mock_api = Mock(spec=RealAPI)
mock_api.get('http://example.com')  # OK
try:
    mock_api.delete('http://example.com')  # AttributeError!
except AttributeError as e:
    print(f"spec enforcement: {e}")

42
5
value
1 2 3
Caught: boom
10
Called with: call('SELECT * FROM users WHERE id=1')
spec enforcement: Mock object has no attribute 'delete'

Key Points

•patch() replaces objects temporarily; patch where USED, not where defined
•MagicMock supports magic methods; Mock is simpler
•side_effect for sequences, exceptions, or custom functions
•spec= restricts mock to the real object's interface

Gotchas

•Patching the wrong location is the #1 mistake -- always patch where the name is looked up
•Mocks accept ANY attribute/call by default -- use spec to catch typos
•assert_called_with checks only the LAST call -- use assert_any_call for any call
•Forgetting to call assert_called_once() (no parentheses) silently passes -- it returns a Mock!

patch() temporarily replaces objects for testing. Mock()/MagicMock() creates fake objects. Key rule: patch where the object is USED, not where defined. Use spec= for type safety.

•Patch where USED, not where defined
•spec= prevents using non-existent attributes

from unittest.mock import Mock, patch

mock_db = Mock()
mock_db.query.return_value = [{"id": 1}]
result = mock_db.query("SELECT *")
mock_db.query.assert_called_once()

# patch as context manager
with patch('mymodule.requests.get') as mock_get:
    mock_get.return_value.status_code = 200

mock.assert_called_once without () silently passes (returns a Mock)

Question 6 / 12

What are test doubles and how do they differ (mock, stub, spy, fake)?

Test doubles are objects that stand in for real dependencies during testing. There are several types:

Stub

Returns predetermined responses. Does NOT verify interactions.

stub.get_price.return_value = 9.99

Mock

Records interactions and verifies expectations (was this called? with what arguments?).

mock.send_email.assert_called_once_with('user@test.com')

Spy

Wraps the real object, recording calls while still executing the real implementation.

spy = Mock(wraps=real_object)

Fake

A working implementation simplified for testing (e.g., in-memory database instead of PostgreSQL).

class FakeDB:
    def __init__(self):
        self._data = {}
    def insert(self, key, value):
        self._data[key] = value

Dummy

Passed around but never used. Fills parameter requirements.

dummy = object()  # just needs to exist

Pseudo Code

Stub:  provides canned answers, no verification
Mock:  records calls, verifies interactions
Spy:   wraps real object, records calls
Fake:  simplified working implementation
Dummy: placeholder, never actually used

Code

from unittest.mock import Mock, MagicMock, patch, create_autospec

class PaymentGateway:
    def charge(self, amount, card_number):
        # Real: calls Stripe API
        pass

    def refund(self, transaction_id):
        # Real: calls Stripe refund API
        pass

class OrderService:
    def __init__(self, payment_gateway, email_service):
        self.payment = payment_gateway
        self.email = email_service

    def place_order(self, amount, card, user_email):
        result = self.payment.charge(amount, card)
        if result['status'] == 'success':
            self.email.send(user_email, 'Order confirmed!')
            return True
        return False

# 1. STUB: provides predetermined responses
def test_with_stub():
    payment_stub = Mock()
    payment_stub.charge.return_value = {'status': 'success', 'id': 'txn_123'}
    email_stub = Mock()  # don't care about email calls

    service = OrderService(payment_stub, email_stub)
    result = service.place_order(99.99, '4111', 'user@test.com')

    assert result is True  # we only verify the return value

test_with_stub()

# 2. MOCK: verifies interactions
def test_with_mock():
    payment_mock = Mock()
    payment_mock.charge.return_value = {'status': 'success', 'id': 'txn_123'}
    email_mock = Mock()

    service = OrderService(payment_mock, email_mock)
    service.place_order(99.99, '4111', 'user@test.com')

    # Verify interactions
    payment_mock.charge.assert_called_once_with(99.99, '4111')
    email_mock.send.assert_called_once_with('user@test.com', 'Order confirmed!')

test_with_mock()

# 3. SPY: wraps real object
class RealCalculator:
    def add(self, a, b):
        return a + b
    def multiply(self, a, b):
        return a * b

def test_with_spy():
    real_calc = RealCalculator()
    spy_calc = Mock(wraps=real_calc)  # spy

    result = spy_calc.add(2, 3)  # calls real implementation
    assert result == 5  # real result
    spy_calc.add.assert_called_once_with(2, 3)  # also tracks the call

test_with_spy()

# 4. FAKE: simplified implementation
class FakeDatabase:
    def __init__(self):
        self._store = {}

    def insert(self, table, data):
        if table not in self._store:
            self._store[table] = []
        self._store[table].append(data)

    def query(self, table, **filters):
        rows = self._store.get(table, [])
        for key, value in filters.items():
            rows = [r for r in rows if r.get(key) == value]
        return rows

def test_with_fake():
    fake_db = FakeDatabase()
    fake_db.insert('users', {'id': 1, 'name': 'Alice'})
    fake_db.insert('users', {'id': 2, 'name': 'Bob'})

    results = fake_db.query('users', name='Alice')
    assert len(results) == 1
    assert results[0]['name'] == 'Alice'

test_with_fake()

# 5. DUMMY: placeholder
def test_with_dummy():
    dummy_logger = object()  # never actually used
    payment = Mock()
    payment.charge.return_value = {'status': 'fail'}
    email = Mock()

    service = OrderService(payment, email)
    result = service.place_order(10, '4111', 'x@t.com')
    assert result is False
    email.send.assert_not_called()  # email never used (dummy-like behavior)

test_with_dummy()

Key Points

•Stub: canned responses, no verification of interactions
•Mock: records and verifies interactions (the most common in Python)
•Spy: wraps real object with Mock(wraps=obj) -- real behavior + tracking
•Fake: simplified working implementation (in-memory DB, etc.)

Gotchas

•Python's Mock class can act as any test double type -- the distinction is how you USE it
•Over-mocking leads to fragile tests that break on refactoring without catching real bugs
•Mocking return values (stubs) tests different things than verifying calls (mocks)
•Fakes need their own tests to ensure they behave like the real thing

Test doubles: Stub (canned responses), Mock (verifies interactions), Spy (wraps real + tracks), Fake (simplified implementation), Dummy (placeholder). In Python, Mock class serves most roles.

•Stub: returns data. Mock: verifies calls. Spy: real + tracking. Fake: simplified.
•Python Mock class serves multiple roles

from unittest.mock import Mock

# Stub: set return value, don't verify
stub = Mock()
stub.get.return_value = 42

# Mock: verify interactions
mock = Mock()
mock.send('hello')
mock.send.assert_called_once_with('hello')

# Spy: real behavior + tracking
spy = Mock(wraps=real_object)

Over-mocking makes tests brittle

Question 7 / 12

How do you test for exceptions in both unittest and pytest?

Testing that code raises expected exceptions is critical for error handling verification.

pytest approach:

with pytest.raises(ExceptionType, match='pattern'):
    code_that_raises()

unittest approach:

with self.assertRaises(ExceptionType):
    code_that_raises()

Key features:

Both support context manager style
pytest.raises provides the exception info for further inspection
Both support checking exception message (pytest: match=, unittest: assertRaisesRegex)
Can verify exception attributes, chained exceptions, etc.

Pseudo Code

pytest:
  with pytest.raises(ValueError, match='invalid'):
      function_that_raises()

unittest:
  with self.assertRaises(ValueError):
      function_that_raises()

  # or with message check:
  with self.assertRaisesRegex(ValueError, 'invalid'):
      function_that_raises()

Code

import pytest
import unittest

def divide(a, b):
    if b == 0:
        raise ZeroDivisionError("Cannot divide by zero")
    if not isinstance(a, (int, float)):
        raise TypeError(f"Expected number, got {type(a).__name__}")
    return a / b

# pytest: basic exception testing
def test_divide_by_zero_pytest():
    with pytest.raises(ZeroDivisionError):
        divide(1, 0)

# pytest: check exception message with match (regex)
def test_divide_by_zero_message():
    with pytest.raises(ZeroDivisionError, match="Cannot divide"):
        divide(1, 0)

# pytest: inspect exception details
def test_divide_type_error():
    with pytest.raises(TypeError) as exc_info:
        divide("hello", 2)

    assert "Expected number" in str(exc_info.value)
    assert exc_info.type is TypeError
    # exc_info.value is the actual exception object
    assert "str" in str(exc_info.value)

# pytest: test that NO exception is raised
def test_divide_success():
    result = divide(10, 2)  # should not raise
    assert result == 5.0

# pytest: test exception with specific attributes
class CustomError(Exception):
    def __init__(self, message, code):
        super().__init__(message)
        self.code = code

def risky_operation():
    raise CustomError("Not found", code=404)

def test_custom_exception_attributes():
    with pytest.raises(CustomError) as exc_info:
        risky_operation()
    assert exc_info.value.code == 404
    assert str(exc_info.value) == "Not found"

# unittest style
class TestDivide(unittest.TestCase):
    def test_divide_by_zero(self):
        with self.assertRaises(ZeroDivisionError):
            divide(1, 0)

    def test_divide_by_zero_message(self):
        with self.assertRaisesRegex(ZeroDivisionError, "Cannot divide"):
            divide(1, 0)

    def test_type_error(self):
        with self.assertRaises(TypeError) as ctx:
            divide("hello", 2)
        self.assertIn("Expected number", str(ctx.exception))

# Testing that a function does NOT raise
def test_no_exception():
    # If this raises, the test fails automatically
    result = divide(10, 5)
    assert result == 2.0

# Testing warnings
import warnings

def deprecated_function():
    warnings.warn("This is deprecated", DeprecationWarning)
    return 42

def test_deprecation_warning():
    with pytest.warns(DeprecationWarning, match="deprecated"):
        result = deprecated_function()
    assert result == 42

Key Points

•pytest.raises(ExcType, match='regex') is the pytest way
•self.assertRaises / self.assertRaisesRegex for unittest
•Use 'as exc_info' to inspect exception attributes
•pytest.warns() tests that warnings are issued

Gotchas

•pytest.raises match parameter uses regex, not plain string matching
•If the code inside 'with pytest.raises()' does NOT raise, the test FAILS
•assertRaises catches subclasses too -- ValueError catches ValueError but not TypeError
•Do not catch too broad exceptions (Exception) -- test for the specific type

pytest: with pytest.raises(ExcType, match='pattern'). unittest: with self.assertRaises(ExcType). Use as exc_info to inspect the exception object.

•pytest.raises for exception testing with optional match regex
•exc_info.value gives the actual exception object

import pytest

def test_raises():
    with pytest.raises(ValueError, match="invalid"):
        raise ValueError("invalid input")

def test_inspect():
    with pytest.raises(KeyError) as exc_info:
        {}['missing']
    assert 'missing' in str(exc_info.value)

match uses regex, not string equality

Question 8 / 12

How do setUp/tearDown work in unittest vs pytest fixtures?

unittest: setUp / tearDown

setUp(): Runs before EACH test method
tearDown(): Runs after EACH test method (even if test fails)
setUpClass() / tearDownClass(): Runs once per class
setUpModule() / tearDownModule(): Runs once per module

pytest: fixtures with yield

@pytest.fixture: Function that provides setup/teardown via yield
Scope controls lifecycle: function, class, module, session
Fixtures are composable (can depend on each other)
Only invoked when actually requested by a test

Key difference:

unittest setUp runs for ALL test methods in the class (always). pytest fixtures only run when explicitly requested by a test (on-demand).

Pseudo Code

unittest:
  setUpModule()           # once per module
    setUpClass()          # once per class
      setUp()             # before EACH test
      test_method()       # the test
      tearDown()          # after EACH test
    tearDownClass()       # once per class
  tearDownModule()        # once per module

pytest:
  @fixture(scope='session')   # once per session
  @fixture(scope='module')    # once per module
  @fixture(scope='class')     # once per class
  @fixture(scope='function')  # before/after each test (default)

Code

import unittest
import pytest

# unittest approach
class TestWithUnittest(unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        """Run once before all tests in this class."""
        cls.shared_resource = {"db": "connected"}
        print("\nsetUpClass: DB connected")

    def setUp(self):
        """Run before EACH test method."""
        self.test_data = [1, 2, 3]
        print("setUp: created test data")

    def test_append(self):
        self.test_data.append(4)
        self.assertEqual(len(self.test_data), 4)

    def test_remove(self):
        self.test_data.remove(1)
        self.assertEqual(len(self.test_data), 2)

    def tearDown(self):
        """Run after EACH test method."""
        self.test_data.clear()
        print("tearDown: cleaned test data")

    @classmethod
    def tearDownClass(cls):
        """Run once after all tests in this class."""
        cls.shared_resource.clear()
        print("tearDownClass: DB disconnected")

# pytest approach (equivalent)
@pytest.fixture(scope='class')
def shared_resource():
    resource = {"db": "connected"}
    print("\nFixture setup: DB connected")
    yield resource
    resource.clear()
    print("Fixture teardown: DB disconnected")

@pytest.fixture
def test_data():
    data = [1, 2, 3]
    print("Fixture setup: created test data")
    yield data
    data.clear()
    print("Fixture teardown: cleaned test data")

def test_append(test_data):
    test_data.append(4)
    assert len(test_data) == 4

def test_remove(test_data):
    test_data.remove(1)
    assert len(test_data) == 2

# pytest fixture advantage: composable
@pytest.fixture
def db_connection():
    conn = {"connected": True}
    yield conn
    conn["connected"] = False

@pytest.fixture
def user_repo(db_connection):
    return {"db": db_connection, "table": "users"}

@pytest.fixture
def sample_user(user_repo):
    user = {"id": 1, "name": "Alice"}
    user_repo["last_created"] = user
    yield user

def test_user_creation(sample_user, user_repo):
    # db_connection -> user_repo -> sample_user (chain)
    assert sample_user["name"] == "Alice"
    assert user_repo["db"]["connected"] is True

# pytest advantage: selective (only runs what's needed)
def test_simple():
    # This test does NOT trigger any fixture setup
    assert 1 + 1 == 2

Key Points

•unittest: setUp/tearDown run for every test; setUpClass for once per class
•pytest: fixtures with yield, only run when requested by name
•pytest fixtures are composable -- chain dependencies naturally
•pytest fixtures are on-demand; setUp runs for ALL tests in the class

Gotchas

•unittest tearDown runs even if setUp fails (can cause confusing errors)
•setUpClass/tearDownClass must be @classmethod in unittest
•Mixing pytest fixtures with unittest TestCase has limitations (no yield fixtures)
•pytest fixture teardown (after yield) runs even if the test fails

unittest: setUp()/tearDown() per test, setUpClass()/tearDownClass() per class. pytest: @fixture with yield for setup/teardown, composable, on-demand, with scope control.

•unittest: always runs; pytest fixtures: on-demand
•pytest yield separates setup from teardown

# unittest
class TestX(unittest.TestCase):
    def setUp(self):
        self.data = [1, 2, 3]
    def tearDown(self):
        self.data.clear()

# pytest (equivalent)
@pytest.fixture
def data():
    d = [1, 2, 3]
    yield d
    d.clear()

setUpClass must be a @classmethod

Question 9 / 12

What is code coverage and how do you measure it with pytest?

Code coverage measures what percentage of your code is executed during tests. It helps identify untested code paths.

Types of coverage:

Line coverage: Which lines were executed
Branch coverage: Whether both True and False paths of conditionals were taken
Function coverage: Which functions were called
Statement coverage: Which statements were executed

Tools:

coverage.py: The standard Python coverage tool
pytest-cov: pytest plugin wrapping coverage.py

Important caveat:

100% coverage does NOT mean bug-free code. Coverage measures which code ran, not whether it ran correctly. You can have 100% coverage with zero meaningful assertions.

Pseudo Code

# Run tests with coverage
pytest --cov=mypackage --cov-report=html

# Coverage report shows:
#   Name              Stmts   Miss  Cover
#   mypackage/app.py     50      5    90%
#   mypackage/db.py      30      0   100%

Code

# Installation
# pip install pytest-cov

# Example module to test: calculator.py
class Calculator:
    def add(self, a, b):
        return a + b

    def divide(self, a, b):
        if b == 0:
            raise ZeroDivisionError("Cannot divide by zero")
        return a / b

    def classify_number(self, n):
        if n > 0:
            return "positive"
        elif n < 0:
            return "negative"
        else:
            return "zero"

# test_calculator.py
import pytest

@pytest.fixture
def calc():
    return Calculator()

def test_add(calc):
    assert calc.add(1, 2) == 3

def test_divide(calc):
    assert calc.divide(10, 2) == 5.0

def test_divide_by_zero(calc):
    with pytest.raises(ZeroDivisionError):
        calc.divide(1, 0)

def test_positive(calc):
    assert calc.classify_number(5) == "positive"

def test_negative(calc):
    assert calc.classify_number(-3) == "negative"

# Missing: test for classify_number(0) -- "zero" branch uncovered!

# Running with coverage:
# pytest --cov=calculator --cov-report=term-missing
#
# Output:
# Name              Stmts   Miss  Cover   Missing
# calculator.py        12      1    92%   15
# (line 15 is the 'return "zero"' line)

# pytest --cov=calculator --cov-report=html
# Opens HTML report with line-by-line highlighting

# pyproject.toml configuration
# [tool.pytest.ini_options]
# addopts = "--cov=src --cov-report=term-missing --cov-branch"
#
# [tool.coverage.run]
# branch = true
# source = ["src"]
#
# [tool.coverage.report]
# fail_under = 80
# exclude_lines = [
#     "pragma: no cover",
#     "if TYPE_CHECKING:",
#     "if __name__ == .__main__.",
# ]

# Excluding lines from coverage
def debug_function():  # pragma: no cover
    """This is excluded from coverage."""
    pass

Key Points

•pytest-cov integrates coverage.py with pytest seamlessly
•Branch coverage (--cov-branch) is more thorough than line coverage
•--cov-report=term-missing shows which lines are uncovered
•Configure minimum coverage with fail_under in pyproject.toml

Gotchas

•100% coverage does not mean correct code -- assertions matter more than coverage numbers
•Branch coverage reveals untested conditional paths that line coverage misses
•Coverage can be misleading for dynamically generated code or meta-programming
•Excluding too many lines with 'pragma: no cover' defeats the purpose

Code coverage measures which code lines/branches execute during tests. Use pytest --cov=package --cov-report=term-missing with pytest-cov. 100% coverage != bug-free code.

•pytest-cov wraps coverage.py for easy integration
•Branch coverage is more thorough than line coverage

# pip install pytest-cov
# pytest --cov=mypackage --cov-report=term-missing --cov-branch

# pyproject.toml
# [tool.coverage.report]
# fail_under = 80

High coverage does not guarantee correct tests -- assertions matter

Question 10 / 12

What is Test-Driven Development (TDD) and how do you practice it in Python?

Test-Driven Development (TDD) is a software development methodology where you write tests BEFORE writing the implementation code.

The TDD cycle (Red-Green-Refactor):

RED: Write a failing test for the feature you want to implement
GREEN: Write the minimal code to make the test pass
REFACTOR: Clean up the code while keeping all tests passing
Repeat

Benefits:

Forces you to think about the interface before implementation
Produces comprehensive test coverage naturally
Leads to simpler, more modular designs
Catches bugs immediately
Tests serve as documentation

TDD rules (Robert C. Martin):

Write no production code except to make a failing test pass
Write only enough of a test to demonstrate a failure
Write only enough production code to make the test pass

Pseudo Code

TDD Cycle:
  1. RED:      Write test -> Run -> FAILS (expected)
  2. GREEN:    Write minimal code -> Run -> PASSES
  3. REFACTOR: Clean up -> Run -> Still PASSES
  4. Repeat for next requirement

Code

import pytest

# TDD Example: Building a Stack data structure

# Step 1 (RED): Write a failing test
def test_stack_is_empty_on_creation():
    stack = Stack()
    assert stack.is_empty() is True

# Run: NameError: name 'Stack' is not defined (RED!)

# Step 2 (GREEN): Minimal code to pass
class Stack:
    def is_empty(self):
        return True

# Run: PASSES (GREEN!)

# Step 3 (RED): Next test
def test_stack_not_empty_after_push():
    stack = Stack()
    stack.push(1)
    assert stack.is_empty() is False

# Run: AttributeError: 'Stack' has no attribute 'push' (RED!)

# Step 4 (GREEN): Add push, fix is_empty
class Stack:
    def __init__(self):
        self._items = []

    def is_empty(self):
        return len(self._items) == 0

    def push(self, item):
        self._items.append(item)

# Run: PASSES (GREEN!)

# Step 5 (RED): Test pop
def test_pop_returns_last_pushed():
    stack = Stack()
    stack.push(42)
    assert stack.pop() == 42

def test_pop_removes_element():
    stack = Stack()
    stack.push(1)
    stack.push(2)
    stack.pop()
    assert stack.pop() == 1

def test_pop_empty_raises():
    stack = Stack()
    with pytest.raises(IndexError, match="empty"):
        stack.pop()

# Step 6 (GREEN): Implement pop
class Stack:
    def __init__(self):
        self._items = []

    def is_empty(self):
        return len(self._items) == 0

    def push(self, item):
        self._items.append(item)

    def pop(self):
        if self.is_empty():
            raise IndexError("Cannot pop from empty stack")
        return self._items.pop()

# Step 7 (REFACTOR): Add peek, size, __len__
def test_peek_does_not_remove():
    stack = Stack()
    stack.push(10)
    assert stack.peek() == 10
    assert stack.is_empty() is False

def test_stack_length():
    stack = Stack()
    stack.push(1)
    stack.push(2)
    assert len(stack) == 2

# Final implementation after full TDD cycle
class Stack:
    def __init__(self):
        self._items = []

    def is_empty(self):
        return len(self._items) == 0

    def push(self, item):
        self._items.append(item)

    def pop(self):
        if self.is_empty():
            raise IndexError("Cannot pop from empty stack")
        return self._items.pop()

    def peek(self):
        if self.is_empty():
            raise IndexError("Cannot peek empty stack")
        return self._items[-1]

    def __len__(self):
        return len(self._items)

    def __repr__(self):
        return f"Stack({self._items})"

# All tests pass -- feature complete with full coverage!

Key Points

•Write the test FIRST, then the code to make it pass
•Red-Green-Refactor cycle: fail, pass, clean up
•Write the MINIMAL code to pass each test
•Tests serve as living documentation and safety net

Gotchas

•TDD feels slow at first but pays off in fewer bugs and better design
•Do not skip the RED step -- if the test passes immediately, something is wrong
•Do not refactor and add features at the same time -- one step at a time
•TDD works best for business logic; UI and integration tests may follow different patterns

TDD: write a failing test (RED), write minimal code to pass (GREEN), clean up (REFACTOR), repeat. Forces good design and comprehensive tests.

•Test first, code second, refactor third
•Minimal code at each step

# RED: write failing test
def test_add():
    calc = Calculator()
    assert calc.add(1, 2) == 3  # FAILS - no Calculator yet

# GREEN: minimal code
class Calculator:
    def add(self, a, b): return a + b  # PASSES

# REFACTOR: clean up, keep tests green

If a new test passes immediately without code changes, the test may be wrong

Question 11 / 12

How does property-based testing with Hypothesis work?

Property-based testing (PBT) tests that certain properties hold true for ALL possible inputs, not just hand-picked examples. Hypothesis is Python's PBT library.

How it works:

You describe the properties your code should satisfy
You describe the shape of valid inputs using strategies
Hypothesis generates hundreds of random test cases
If a failure is found, Hypothesis shrinks it to the smallest failing example

vs example-based testing:

Example-based: test_sort([3,1,2]) -- tests ONE specific input
Property-based: test_sort(any_list) -- tests HUNDREDS of random inputs

Common strategies:

st.integers(), st.floats(), st.text(), st.booleans()
st.lists(), st.dictionaries(), st.tuples()
st.one_of(), st.sampled_from()
st.composite() for custom strategies

Pseudo Code

Property: sorted output should have same length as input
Property: every element in sorted should be <= next element
Property: sorted(sorted(x)) == sorted(x) (idempotent)

Hypothesis generates: [], [1], [5,3], [0,0,0], [-1,99,3,3], ...
If any property fails, shrinks to minimal failing case

Code

from hypothesis import given, settings, assume, example
from hypothesis import strategies as st
import pytest

# Basic property-based test
@given(st.lists(st.integers()))
def test_sort_preserves_length(lst):
    """Sorting should not change the number of elements."""
    assert len(sorted(lst)) == len(lst)

@given(st.lists(st.integers()))
def test_sort_is_ordered(lst):
    """Every element should be <= the next."""
    result = sorted(lst)
    for i in range(len(result) - 1):
        assert result[i] <= result[i + 1]

@given(st.lists(st.integers()))
def test_sort_is_idempotent(lst):
    """Sorting twice gives the same result as sorting once."""
    assert sorted(sorted(lst)) == sorted(lst)

@given(st.lists(st.integers()))
def test_sort_preserves_elements(lst):
    """Sorted list should contain the same elements."""
    assert sorted(sorted(lst)) == sorted(lst)
    from collections import Counter
    assert Counter(sorted(lst)) == Counter(lst)

# Testing a custom function
def encode_decode(text):
    """Simple encode/decode that should round-trip."""
    encoded = text.encode('utf-8')
    return encoded.decode('utf-8')

@given(st.text())
def test_encode_decode_roundtrip(text):
    """Encoding then decoding should return the original."""
    assert encode_decode(text) == text

# Using assume() to filter inputs
@given(st.integers(), st.integers())
def test_division_roundtrip(a, b):
    """(a / b) * b should approximately equal a."""
    assume(b != 0)  # skip if b is 0
    assume(abs(b) > 1e-10)  # skip tiny divisors
    result = (a / b) * b
    assert abs(result - a) < 1e-6

# Custom strategies
@st.composite
def user_strategy(draw):
    name = draw(st.text(min_size=1, max_size=50,
                         alphabet=st.characters(whitelist_categories=('L',))))
    age = draw(st.integers(min_value=0, max_value=150))
    email = draw(st.emails())
    return {"name": name, "age": age, "email": email}

@given(user_strategy())
def test_user_has_required_fields(user):
    assert "name" in user
    assert "age" in user
    assert 0 <= user["age"] <= 150

# Explicit examples alongside random ones
@given(st.integers())
@example(0)      # always test zero
@example(-1)     # always test negative
@example(2**31)  # always test large int
def test_abs_is_non_negative(n):
    assert abs(n) >= 0

# Settings for controlling test behavior
@settings(max_examples=500, deadline=None)
@given(st.lists(st.integers(), min_size=1))
def test_max_in_list(lst):
    m = max(lst)
    assert m in lst
    assert all(x <= m for x in lst)

Key Points

•Test PROPERTIES (invariants) instead of specific examples
•Hypothesis generates hundreds of random inputs and shrinks failures to minimal cases
•Strategies describe the shape of valid inputs (integers, text, lists, etc.)
•Finds edge cases humans often miss (empty lists, negative numbers, unicode, etc.)

Gotchas

•Property-based tests complement example-based tests -- don't replace all examples
•assume() filters inputs but too much filtering makes tests slow (use constrained strategies instead)
•Hypothesis stores a database of previously found failures and replays them
•Some properties are hard to express -- 'oracle testing' (comparing to a known-good implementation) is an alternative

Hypothesis generates random inputs to test properties (invariants). Use @given(st.integers()) to describe input types. Failures are automatically shrunk to minimal examples.

•Test properties, not specific examples
•Automatic shrinking finds minimal failing inputs

from hypothesis import given
from hypothesis import strategies as st

@given(st.lists(st.integers()))
def test_sort_preserves_length(lst):
    assert len(sorted(lst)) == len(lst)

@given(st.text())
def test_reverse_reverse_is_identity(s):
    assert s[::-1][::-1] == s

Complement example-based tests, don't replace them entirely

Question 12 / 12

How do you test asynchronous code in Python with pytest?

Testing async code requires running coroutines within an event loop. The pytest-asyncio plugin makes this seamless.

Setup:

pip install pytest-asyncio

Key features:

@pytest.mark.asyncio: Marks a test as async (runs in event loop)
Async fixtures with @pytest_asyncio.fixture
Mode configuration: auto (all async tests auto-detected) or strict (explicit marking)
Works with asyncio.gather, asyncio.create_task, etc.

Alternative: `anyio` for framework-agnostic async testing (asyncio + trio)

Pseudo Code

# Install: pip install pytest-asyncio

# Mark test as async
@pytest.mark.asyncio
async def test_fetch():
    result = await async_function()
    assert result == expected

# Async fixture
@pytest_asyncio.fixture
async def db():
    conn = await create_connection()
    yield conn
    await conn.close()

Code

import pytest
import asyncio

# pyproject.toml:
# [tool.pytest.ini_options]
# asyncio_mode = "auto"  # or "strict"

# Async function to test
async def fetch_data(url):
    await asyncio.sleep(0.01)  # simulate I/O
    return {"url": url, "data": "response"}

async def process_batch(urls):
    tasks = [fetch_data(url) for url in urls]
    return await asyncio.gather(*tasks)

async def transform(value):
    await asyncio.sleep(0.01)
    if not isinstance(value, (int, float)):
        raise TypeError(f"Expected number, got {type(value).__name__}")
    return value * 2

# Basic async test
@pytest.mark.asyncio
async def test_fetch_data():
    result = await fetch_data("https://api.example.com")
    assert result["url"] == "https://api.example.com"
    assert "data" in result

# Testing async exceptions
@pytest.mark.asyncio
async def test_transform_type_error():
    with pytest.raises(TypeError, match="Expected number"):
        await transform("not a number")

# Testing concurrent operations
@pytest.mark.asyncio
async def test_process_batch():
    urls = ["url1", "url2", "url3"]
    results = await process_batch(urls)
    assert len(results) == 3
    assert all("data" in r for r in results)

# Async fixtures
import pytest_asyncio

@pytest_asyncio.fixture
async def async_client():
    """Async fixture with setup/teardown."""
    client = {"connected": True}
    yield client
    client["connected"] = False  # async teardown

@pytest.mark.asyncio
async def test_with_async_fixture(async_client):
    assert async_client["connected"] is True

# Parametrized async tests
@pytest.mark.asyncio
@pytest.mark.parametrize("input_val,expected", [
    (5, 10),
    (0, 0),
    (-3, -6),
])
async def test_transform_parametrized(input_val, expected):
    result = await transform(input_val)
    assert result == expected

# Testing timeouts
@pytest.mark.asyncio
async def test_timeout():
    async def slow_operation():
        await asyncio.sleep(10)

    with pytest.raises(asyncio.TimeoutError):
        await asyncio.wait_for(slow_operation(), timeout=0.1)

# Mocking async functions
from unittest.mock import AsyncMock, patch

async def get_user(user_id):
    # Would normally call a database
    pass

@pytest.mark.asyncio
async def test_with_async_mock():
    mock_get = AsyncMock(return_value={"id": 1, "name": "Alice"})

    with patch('__main__.get_user', mock_get):
        result = await get_user(1)
        assert result["name"] == "Alice"
        mock_get.assert_awaited_once_with(1)

Key Points

•pytest-asyncio lets you write async test functions with @pytest.mark.asyncio
•AsyncMock (Python 3.8+) mocks coroutines; assert_awaited_once_with for verification
•Async fixtures use @pytest_asyncio.fixture with async def + yield
•asyncio_mode='auto' in config auto-detects async tests

Gotchas

•Forgetting @pytest.mark.asyncio makes the test silently not run the coroutine
•AsyncMock is needed for mocking coroutines -- regular Mock returns a Mock, not a coroutine
•Mixing sync and async fixtures requires care -- async fixtures cannot be used in sync tests
•Event loop scope matters: function-scoped (default) creates a new loop per test

Use pytest-asyncio with @pytest.mark.asyncio for async tests. Use AsyncMock for mocking coroutines. Async fixtures use @pytest_asyncio.fixture.

•@pytest.mark.asyncio for async tests
•AsyncMock for mocking coroutines

import pytest
from unittest.mock import AsyncMock

@pytest.mark.asyncio
async def test_async_func():
    result = await some_async_function()
    assert result == expected

@pytest.mark.asyncio
async def test_mock_async():
    mock = AsyncMock(return_value=42)
    assert await mock() == 42
    mock.assert_awaited_once()

Forgetting the marker means the coroutine never executes

Built by onllm.dev

Home GitHub Support awesomePrep

What are the key differences between unittest and pytest?

unittest (standard library)

pytest (third-party)

When to use which:

How do pytest fixtures work and what are their scopes?

Scopes (lifecycle of the fixture):

Key features:

How does pytest.mark.parametrize work for data-driven testing?

Syntax:

Features:

What is conftest.py and how does pytest use it?

What goes in conftest.py:

Scope rules:

How do you use unittest.mock.patch and MagicMock for mocking?

Key classes:

The patch rule:

Assertions on mocks:

What are test doubles and how do they differ (mock, stub, spy, fake)?

Stub

Mock

Spy

Fake

Dummy

How do you test for exceptions in both unittest and pytest?

pytest approach:

unittest approach:

Key features:

How do setUp/tearDown work in unittest vs pytest fixtures?

unittest: setUp / tearDown

pytest: fixtures with yield

Key difference:

What is code coverage and how do you measure it with pytest?

Types of coverage:

Tools:

Important caveat:

What is Test-Driven Development (TDD) and how do you practice it in Python?

The TDD cycle (Red-Green-Refactor):

Benefits:

TDD rules (Robert C. Martin):

How does property-based testing with Hypothesis work?

How it works:

vs example-based testing:

Common strategies:

How do you test asynchronous code in Python with pytest?

Setup:

Key features:

Alternative: anyio for framework-agnostic async testing (asyncio + trio)

Testing (unittest, pytest, mocking)

The `patch` rule:

Alternative: `anyio` for framework-agnostic async testing (asyncio + trio)