Dependency Injection: Write Testable, Flexible Python

Dependency injection (DI) is a technique where an object receives the other objects it needs — its dependencies — from the outside rather than creating them internally. It sounds like a small shift, but it fundamentally changes how testable, maintainable, and flexible your code is. It’s also the core of how FastAPI handles database connections, authentication, and shared services.

The Problem: Tight Coupling

When a class creates its own dependencies, it is tightly coupled to their concrete implementations. Changing one dependency means changing the class itself, and testing becomes painful because you can’t swap in a fake.

# ❌ Tight coupling — StudentService always uses the real database
class StudentRepository:
    def get_all(self) -> list[str]:
        # In reality: query a production database
        return ["Alice", "Bob", "Charlie"]

class StudentService:
    def __init__(self):
        self.repo = StudentRepository()    # created internally — no way to swap

    def list_students(self) -> list[str]:
        return self.repo.get_all()

# To test StudentService you must hit the real database every time
service = StudentService()
print(service.list_students())

The Solution: Inject from Outside

Move dependency creation to the caller. The class just declares what it needs in its constructor and uses whatever it receives.

# ✅ Loose coupling — StudentService accepts any compatible repository
class StudentRepository:
    def get_all(self) -> list[str]:
        return ["Alice", "Bob", "Charlie"]

class StudentService:
    def __init__(self, repository: StudentRepository):
        self.repo = repository   # injected from outside

    def list_students(self) -> list[str]:
        return self.repo.get_all()

# Wire up dependencies at the entry point
repo    = StudentRepository()
service = StudentService(repo)          # dependency injected here
print(service.list_students())          # ['Alice', 'Bob', 'Charlie']

Now StudentService doesn’t care how the repository works — only that it has a get_all() method.

Why DI Improves Testability

Swapping the real repository for a fake one in tests becomes trivial:

# A mock repository that returns predictable test data
class MockStudentRepository:
    def get_all(self) -> list[str]:
        return ["TestStudent1", "TestStudent2"]

# Test the service without touching a real database
service = StudentService(MockStudentRepository())
result  = service.list_students()
assert result == ["TestStudent1", "TestStudent2"]   # ✅ fast, isolated test

Injecting Interfaces Instead of Concrete Classes

For maximum flexibility, depend on an Abstract Base Class (an interface) rather than a concrete class. Any class that implements the ABC can be swapped in.

from abc import ABC, abstractmethod

class AbstractStudentRepository(ABC):
    @abstractmethod
    def get_all(self) -> list[str]: ...

    @abstractmethod
    def find_by_id(self, student_id: int) -> dict | None: ...

# Production implementation
class DatabaseStudentRepository(AbstractStudentRepository):
    def get_all(self) -> list[str]:
        # query real database
        return ["Alice", "Bob"]

    def find_by_id(self, student_id: int) -> dict | None:
        return {"id": student_id, "name": "Alice"}

# Test / in-memory implementation
class InMemoryStudentRepository(AbstractStudentRepository):
    def __init__(self):
        self._data = {1: "Alice", 2: "Bob"}

    def get_all(self) -> list[str]:
        return list(self._data.values())

    def find_by_id(self, student_id: int) -> dict | None:
        name = self._data.get(student_id)
        return {"id": student_id, "name": name} if name else None

# The service depends on the abstract type — works with either implementation
class StudentService:
    def __init__(self, repository: AbstractStudentRepository):
        self.repo = repository

    def list_students(self) -> list[str]:
        return self.repo.get_all()

    def get_student(self, student_id: int) -> dict | None:
        return self.repo.find_by_id(student_id)

# Swap implementations without changing StudentService
prod_service = StudentService(DatabaseStudentRepository())
test_service = StudentService(InMemoryStudentRepository())

Types of Dependency Injection

Constructor Injection (most common)

Dependencies are passed as constructor parameters. This is the most transparent form — you can see all dependencies at a glance.

class OrderService:
    def __init__(
        self,
        order_repo: OrderRepository,
        payment_service: PaymentService,
        email_service: EmailService,
    ):
        self.order_repo      = order_repo
        self.payment_service = payment_service
        self.email_service   = email_service

Method (Parameter) Injection

The dependency is passed directly to the method that needs it. Useful when only one method requires the dependency, or when the dependency varies per call.

class ReportGenerator:
    def generate(self, data: list[dict], formatter) -> str:
        # formatter is injected at call time
        return formatter.format(data)

generator = ReportGenerator()
report = generator.generate(data, CsvFormatter())

Setter Injection

Dependencies are set through a method after construction. Less common in Python — prefer constructor injection for required dependencies.

class DataProcessor:
    def set_validator(self, validator):
        self.validator = validator

Benefits of Dependency Injection

Testability

Inject mock or in-memory implementations during tests. No real databases, no network calls, no filesystem access — just fast, predictable unit tests.

Flexibility

Swap a SQLite database for PostgreSQL, a fake email service for SendGrid, or a local file store for S3 — without changing the classes that use them.

Separation of concerns

Each class has one job: using its dependencies. The responsibility for creating and wiring dependencies lives in one place (your application entry point or DI framework).

Reusability

A service that accepts an interface rather than a concrete class can be reused across projects, teams, and contexts with minimal changes.

How FastAPI Implements DI with `Depends()`

FastAPI has a built-in DI system. You define dependency functions and declare them on route parameters using Depends(). FastAPI resolves and injects them automatically on every request.

from fastapi import Depends, FastAPI, HTTPException

app = FastAPI()

# ── Simple dependency ──────────────────────────────────────────────────────
def get_repository() -> InMemoryStudentRepository:
    return InMemoryStudentRepository()

def get_service(
    repo: AbstractStudentRepository = Depends(get_repository)
) -> StudentService:
    return StudentService(repo)

# ── Endpoints ──────────────────────────────────────────────────────────────
@app.get("/students")
def list_students(service: StudentService = Depends(get_service)):
    return service.list_students()

@app.get("/students/{student_id}")
def get_student(
    student_id: int,
    service: StudentService = Depends(get_service)
):
    student = service.get_student(student_id)
    if student is None:
        raise HTTPException(status_code=404, detail="Student not found")
    return student

FastAPI builds the full dependency graph automatically: it calls get_repository(), passes the result to get_service(), and passes that result to your endpoint — all before your handler function runs.

Yield dependencies for resource management

When a dependency needs setup and teardown (like a database session), use yield:

def get_db():
    db = DatabaseSession()    # open connection
    try:
        yield db              # inject into endpoint
    finally:
        db.close()            # guaranteed cleanup after response

@app.get("/products")
def list_products(db = Depends(get_db)):
    return db.query("SELECT * FROM products")

In production FastAPI applications, your dependency chain typically looks like: get_db (database session) → get_repository(db) → get_service(repository) → endpoint. Each layer is independently testable by injecting a mock at the appropriate level.

Quick Summary

Identify dependencies

Any object your class needs to do its work — database, external service, logger, configuration — is a dependency.

Accept them from outside

Declare dependencies as constructor parameters rather than creating them inside __init__. Annotate with an abstract type where possible.

Wire them at the entry point

In a plain Python app, wire dependencies in main.py or an application factory. In FastAPI, use Depends() functions.

Swap for tests

In your test file, construct classes with mock or in-memory implementations. Your business logic classes need zero changes.

Core Python

Advanced Python

Pydantic

Dependency Injection: Write Testable, Flexible Python

The Problem: Tight Coupling

The Solution: Inject from Outside

Why DI Improves Testability

Injecting Interfaces Instead of Concrete Classes

Types of Dependency Injection

Benefits of Dependency Injection

Testability

Flexibility

Separation of concerns

Reusability

How FastAPI Implements DI with `Depends()`

Yield dependencies for resource management

Quick Summary

​The Problem: Tight Coupling

​The Solution: Inject from Outside

​Why DI Improves Testability

​Injecting Interfaces Instead of Concrete Classes

​Types of Dependency Injection

​Benefits of Dependency Injection

Testability

Flexibility

Separation of concerns

Reusability

​How FastAPI Implements DI with Depends()

​Yield dependencies for resource management

​Quick Summary

The Problem: Tight Coupling

The Solution: Inject from Outside

Why DI Improves Testability

Injecting Interfaces Instead of Concrete Classes

Types of Dependency Injection

Benefits of Dependency Injection

How FastAPI Implements DI with `Depends()`

Yield dependencies for resource management

Quick Summary