Testing FastAPI
Exercise routes with TestClient, dependency overrides, and async clients.
Recipe
Quick-reference recipe card - copy-paste ready.
from fastapi import FastAPI
from fastapi.testclient import TestClient
app = FastAPI()
@app.get("/health")
def health() -> dict[str, str]:
return {"status": "ok"}
def test_health():
client = TestClient(app)
r = client.get("/health")
assert r.status_code == 200
assert r.json()["status"] == "ok"When to reach for this:
- Regression tests for routes
- Auth and DB test doubles
- OpenAPI contract checks
Working Example
import pytest
from fastapi import Depends, FastAPI
from fastapi.testclient import TestClient
app = FastAPI()
def get_db():
return {"items": ["fixture"]}
@app.get("/items")
def items(db=Depends(get_db)):
return db["items"]
@pytest.fixture
def client():
app.dependency_overrides[get_db] = lambda: {"items": ["override"]}
with TestClient(app) as c:
yield c
app.dependency_overrides.clear()
def test_items(client):
assert client.get("/items").json() == ["override"]What this demonstrates:
- TestClient smoke test
- pytest fixture with overrides
- Cleanup of overrides
Deep Dive
How It Works
TestClientruns the ASGI app in-process without network.- Overrides replace dependencies for isolated tests.
- Use
httpx.AsyncClientwithASGITransportfor async routes.
Gotchas
- Boundary validation skipped - Invalid data reaches persistence layers.. Fix: Validate with Pydantic or framework forms at the edge..
- Leaking stack traces - Clients see internal errors.. Fix: Map exceptions to stable HTTP responses..
- Blocking async event loops - Workers stall under concurrent load.. Fix: Use async drivers or threadpool wrappers..
- Secrets in source control - Credentials leak via git history.. Fix: Load secrets from env or a vault at runtime..
- Missing observability - Incidents are hard to debug.. Fix: Add structured logs, metrics, and request IDs..
Alternatives
| Alternative | Use When | Don't Use When |
|---|---|---|
| Alternate framework in this cookbook | Team standard or existing monolith | Greenfield API with different constraints |
| Managed BaaS | CRUD-only MVP | Custom auth, workflows, or compliance needs |
| gRPC | Internal high-performance RPC | Public HTTP clients and browser access |
FAQs
When should I adopt testing FastAPI?
Use it when the patterns and trade-offs on this page match your API or data boundary.
What is the top production mistake with testing FastAPI?
Skipping validation, timeouts, or explicit error contracts at the HTTP edge.
How do I test testing FastAPI?
Use the framework test client, override dependencies, and assert status plus JSON shape.
Does testing FastAPI work with Python 3.14?
Yes - examples target Python 3.14 with pinned framework versions from the stack footer.
How does testing FastAPI relate to Pydantic 2?
Validate and serialize at boundaries; keep services working with typed domain objects.
Sync or async?
Prefer async routes when I/O dominates; keep CPU work small or offload to workers.
Where should business logic live?
Thin handlers; services own rules; repositories own queries.
How do I document APIs?
Publish OpenAPI or schema docs that match response models in code.
How do I handle versioning?
Explicit URL or header versioning with deprecation windows - avoid silent breaks.
What should I read next?
Follow the Related links for the next layer of depth in this section.
How do I stay secure?
Authenticate callers, authorize per resource, rate-limit, and never log secrets.
Performance first step?
Measure DB and upstream latency before swapping frameworks.
Related
- FastAPI Basics - Core routes and models
- Dependency Injection - Per-request providers
- Testing FastAPI - Test client patterns
- Deploying FastAPI - Production serving
Stack versions: This page was written for Python 3.14.0 (stable 3.14, maintenance 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, and uv 0.6+.