How do I test Django without creating a test database?

Record your running server with Keploy. It captures the SQL your ORM emits along with the rows returned, then replays both on test runs. Django's test runner is never invoked, so no test database is created, migrated, or destroyed.

Can Keploy mock Django ORM queries?

Yes. Keploy records the Postgres or MySQL wire protocol beneath the ORM, so a .filter() or .get() replays with the exact rows it received. Because the mock is the generated SQL, a query change shows up as a real diff.

Does Keploy work with Django REST Framework?

Yes. Capture happens at the socket rather than inside the view layer, so DRF routers, viewsets, serializers, permission classes, and throttling all execute on every recorded request and are exercised again on replay.

Is Keploy an alternative to Django fixtures?

Yes, for integration tests. Fixtures are serialized model data that drifts from your schema; Keploy captures the rows the request actually read. There is no JSON file to update when a field is added or renamed.

Do I need a separate settings module for Keploy?

No. Keploy runs your app with the settings you already use, so there is no test settings module, no DATABASES override, and no TESTING flag branching through your code. Recording and replay both use your normal configuration.

Is Keploy free for Django projects?

Yes. The Keploy CLI is open source under Apache 2.0 and free to run on any Django project with no seat limits. It is not a pip package, so it never appears in requirements.txt or affects your dependency resolution.

Keploy as a Django testing framework

Keploy tests Django applications by recording real requests through the running server and every ORM query, cache read, and outbound HTTP call they trigger, then replaying all of it as assertions. Django's test runner never creates a database, because there is no test database to create.

Generate Django tests free

keploy record -c "python manage.py runserver"

18.4K+

1.2M+300M+mocks createdSlack

What Keploy gives a Django team

Django 3.2 and above, unchanged

Keploy starts the app through runserver or gunicorn. Function views, class-based views, Django REST Framework, and Django Ninja all record identically because capture happens at the socket.

Django 3.2 and above
runserver or gunicorn
DRF viewsets and serializers
No TestCase subclass needed

Try Keploy for free Explore the docs

The problem

Why Django integration tests slow teams down

The friction is rarely the assertions. It is everything around them — spinning up dependencies, keeping mocks honest, and repairing tests after every refactor.

Book a call Explore the docs

Three ways to do it

Testing Django: by hand, with Django TestCase + test Client, or with Keploy

Django's test runner buys its fidelity with a test database, a full migration run, and a fixture layer. Keploy captures the SQL your ORM emitted instead, so replay never opens a connection.

By hand

Django TestCase + test Client

With Keploy

Select any row for the full comparison, with code.

Get started Book a call

Same coverage, three costs

What you write for Django vs what Keploy records

All three produce the same assertion. Only the third still passes after the next refactor without anyone editing it.

By hand2–4 hours

test_orders_manual.py

hand-written

# Hand-written: the view is called directly with a fake request.

from django.test import RequestFactory

from orders.views import confirm_order

class FakeQuerySet:

def get(self, **kwargs):

return FakeOrder(id="ord_1", amount_minor=4200, state="NEW")

def test_confirm_order(monkeypatch):

monkeypatch.setattr("orders.models.Order.objects", FakeQuerySet())

monkeypatch.setattr(

"orders.payments.charge",

lambda token: {"status": "AUTHORIZED"},

)

request = RequestFactory().post(

"/orders/ord_1/confirm",

data={"payment_token": "tok_123"},

content_type="application/json",

)

response = confirm_order(request, "ord_1")

assert response.status_code == 200

assert response.data["state"] == "CONFIRMED"

Two monkeypatches against import paths, and a request built by hand. Middleware, authentication, and the ORM are all absent from what this proves.

Django TestCase + test Client1–2 hours

test_orders_django.py

tool-assisted

# Django TestCase + test Client + responses.

import responses

from django.test import TestCase

from orders.models import Order

class ConfirmOrderTests(TestCase):

# Loaded into the test database before every test method.

fixtures = ["orders_seed.json"]

def setUp(self):

Order.objects.create(

id="ord_1", amount_minor=4200, state="NEW"

)

@responses.activate

def test_confirm_order(self):

responses.add(

responses.POST,

"https://api.payments.example.com/v1/payment_intents/tok_123/confirm",

json={"status": "AUTHORIZED"},

)

response = self.client.post(

"/orders/ord_1/confirm",

data={"payment_token": "tok_123"},

content_type="application/json",

)

self.assertEqual(response.status_code, 200)

self.assertEqual(response.json()["state"], "CONFIRMED")

Correct and idiomatic — but it needs a test database, every migration applied, a fixture file, and a Stripe body typed out by hand.

With Keploy~5 minutes

test-1.yaml

auto-generated

# Recorded with: keploy record -c 'python manage.py runserver'

# No test database. No migrations. No fixtures.

version: api.keploy.io/v1beta1

kind: Http

name: test-1

spec:

req:

method: POST

url: /orders/ord_1/confirm

header:

Content-Type: application/json

Authorization: Token <captured>

body: '{"payment_token":"tok_123"}'

resp:

status_code: 200

body:

id: "ord_1"

state: "CONFIRMED"

amount_minor: 4200

confirmed_at: "2026-09-02T11:04:18Z"

noise:

- body.confirmed_at

# The ORM query as the SQL it emitted, plus the real Stripe call.

mocks:

- kind: Postgres

operation: 'SELECT "orders"."id", "orders"."amount_minor" FROM "orders" WHERE "orders"."id" = $1'

- kind: Http

url: https://api.payments.example.com/v1/payment_intents/tok_123/confirm

status: 200

The mock is the SQL the ORM actually generated, so a query change caught by a re-record shows up as a real diff instead of a passing fixture.

Times are estimates for authoring one endpoint’s coverage from scratch, not measurements.

Explore the docs Request a trial

Keploy vs the alternatives

Django testing tools, compared

The options a team on Python actually reaches for, and where each one genuinely wins. Select a row for the full comparison.

Keploy

pytest + unittest.mock

VCR.py

responses

Testcontainers

Postman

SmartBear ReadyAPI

Best in classStrongPartialNot covered

Assessments reflect each tool’s documented behaviour, not benchmark measurements.

Request a trial Book a call

How it works

Record your Django app once, replay it forever

Keploy sits below your Django process at the network layer. It watches the calls your app already makes, then serves them back on replay so tests run with no dependencies attached.

Your Django appGET/api/v1/orders/{id}200

RecordingKeploy proxyeBPF · userspace

PostgreSQLPostgres protocol beneath the Django ORM

MySQLMySQL protocol beneath the Django ORM

RedisRESP under django-redis and the cache framework

MongoDBWire protocol under PyMongo, for non-ORM access

+3 more Django dependencies

An example shape of a captured call. Your own endpoints and dependencies come from your real traffic, so nothing here has to be written by hand.

Try Keploy for free Request a trial

Mock coverage

What Keploy mocks for Django, with zero config

6 of the 7 dependencies a typical Django service talks to are stubbed from the recording itself — no mock classes, no fixture files, no containers in CI.

Auto-mocked
PostgreSQLView page
Postgres protocol beneath the Django ORM
Auto-mocked
MySQLView page
MySQL protocol beneath the Django ORM
Auto-mocked
RedisView page
RESP under django-redis and the cache framework
Auto-mocked
MongoDBView page
Wire protocol under PyMongo, for non-ORM access
Auto-mocked
Apache KafkaView page
Kafka protocol under kafka-python
Outbound HTTP
Auto-mocked
Outbound HTTP
Any requests or httpx call from a view or task
Partial
Celery brokers
Task enqueue over the broker protocol

Explore the docs Book a call

Quick start

Your first Django test suite in under five minutes

Every command below runs against your existing Django service. Nothing in your source tree changes.

1
1Install the Keploy CLI
A standalone binary — nothing is added to requirements.txt and no settings change is needed.
curl -sSL https://keploy.io/install.sh | bash
2
2Record your Django server
Use runserver locally or gunicorn to match production more closely. Either records identically.
keploy record -c "python manage.py runserver 8000"
3
3Exercise your endpoints
Each request becomes a test case with the ORM queries and upstream HTTP calls it triggered attached.
curl -X POST localhost:8000/orders/ord_1/confirm -H 'Content-Type: application/json' -H 'Authorization: Token $TOKEN' -d '{"payment_token":"tok_123"}'
4
4Replay in CI
No services: block, no migrate step — replay answers every database call from the recording.
keploy test -c "python manage.py runserver 8000" --delay 10