Unit tests with mocked data miss the bugs that only appear with real data at real scale. Ardent lets you run your full test suite, including destructive operations, against an exact copy of production.
How it works
ardent branch create prints a Postgres URL for the new branch. If you need it again, run ardent branch info regression-run (or ardent branch info when that branch is already checked out).
The examples below assume your tests read DATABASE_URL (Django, SQLAlchemy, Prisma, and most pytest setups do). If yours uses a different variable or a .env file, substitute that.
One-liner: DATABASE_URL='…' npm test sets the variable for just that command. export is easier when you’ll run more than one.
DATABASE_URL (or wire it into your framework), run your test command, then delete the branch. See CI / CD for a GitHub Actions–shaped example.
What this unlocks
- Migration safety: run
ALTER TABLE, DROP COLUMN, schema changes against real data before you ship
- Destructive queries:
DELETE, TRUNCATE, bulk updates; see how much damage they would do — safely
- Index validation: try a new index and see if it actually speeds up your real queries
- Data-dependent bugs: catch edge cases that only exist in production data, not fixtures
Hand it to an AI agent
With the ardent-cli skill installed, a short ask is enough:
Without the skill, paste the full directions:
