Generate Django test data from your models

From models.py to a populated test database

A handful of Django fixtures is fine. A real project is not. Once you have dozens of models, every factory has to know which parent rows exist, which foreign keys to satisfy, and which derived totals to keep in sync. You end up maintaining a second, worse copy of your schema in test code, and it breaks on the next migration.

SeedBase reads your models.py instead. It walks the model graph, resolves the foreign keys, and fills a whole foreign-key-consistent database with realistic distributions. One generation, one fixture, and your test gets a database that looks like production without being production.

• Every customer_id points at a customer that exists, so the data loads with constraints on.
• Realistic distributions and values, not "Premium Widget 1", so your assertions test against data that looks real.
• One fixture replaces the pile of per-model factory_boy factories and the wiring between them.
• No production data leaves the building, so there is no GDPR exposure in the test suite.

Seed a Django test database in pytest

A pytest fixture is just dependency injection: the test declares what it needs in its arguments and the framework provides it. So inject the whole database.

# tests/test_orders.py
def test_pagination(seeded_database):
    # a live connection to a DB full of realistic, FK-consistent data
    rows = seeded_database.execute(
        sqlalchemy.text("SELECT email FROM users LIMIT 5")
    ).fetchall()
    assert all("@" in e for (e,) in rows)

Install with pip install "seedbase[database]". The seeded_database fixture loads a generation into a live database and hands you the connection. Prefer no database at all? The seeded_rows fixture returns {table: [rows]} as an in-memory dict, so you assert against the rows directly. It plays alongside pytest-django, and it is an alternative to loaddata and factory_boy when you want a whole populated database rather than a handful of objects.

Reads real Django projects

Toy schemas are easy. The hard part is the patterns a real Django codebase actually uses, and that is what SeedBase was built against.

• Abstract mixins: a TimeStampedModel base with created_at and updated_at inherited across half your models.
• Model inheritance: concrete and abstract bases resolved into the right tables.
• ForeignKey("self"): self-referential trees and graphs, like a category that has a parent category.
• Implicit id primary keys: the auto-added id field that never shows up in models.py but is real in the database.

SeedBase was tested against a real 20-app Django project with 226 tables, including abstract mixins and ForeignKey("self"). That is where the foreign-key handling and the edge cases came from, not from a tidy three-table demo.

Deterministic and reproducible

Generation is seeded. The same seed produces the same data, every run. That keeps CI reproducible: the same fixture yields the same rows on every machine, so a green build stays green for the right reason. When a test fails, reuse the seed and you reproduce the exact dataset that broke it, instead of chasing a fixture that has since been hand-edited.

Free tier: generate, download, seed

Generation and JSON download are free to use. You do not need push-to-database or any paid feature to seed a Django test database, because the data loads through your own database connection or as plain rows in memory. Generate once, download the JSON, and let your fixture wire it into the test setup.

Try it

There is a runnable example, so you can clone, run the test, and watch a real FK-consistent dataset get seeded into a Django test database. Then point it at your own models.

• Clone the runnable example under examples/pytest/, run the test, and watch the fixture seed a live database.
• Paste a schema and look at the rows in the login-free sandbox, no account needed.
• Drive generation from your editor with the VS Code extension or the JetBrains plugin.
• Read the docs for the pytest fixtures and the model-reading details.
• On another stack? See the Symfony test data and Laravel test data guides, or the test data fixtures hub.