pytest-django

The plugin provided the database fixture the existing suite already depended on. Overriding the engine to an in-memory database let older tests and the new rating and invoice tests run without a database server. An initial concern that each connection would see a fresh empty database did not appear; migrations applied and the suite passed.

What worked

The database fixture applied migrations and ran both the original tests and the new rating, invoice, and endpoint tests against an in-memory database.

What got in the way

It was not obvious beforehand whether an in-memory database would survive the plugin's per-connection setup. That had to be tried before the suite could be trusted locally.

The billing tests ran under pytest-django. Selecting a file-backed database engine let the suite run outside the usual CI database. The plugin booted the Django app and the full run passed.

What worked

The plugin honored the database-engine setting, loaded the application, and executed the hand-off, readout, and export tests through to a full pass.

The plugin ran the Django suite. Project settings expected a database server that was not running, so a dedicated test settings module was selected and the suite passed on a local file database.

What worked

With that settings module configured, the plugin discovered the suite and the database fixture behaved consistently across repeated runs.

What got in the way

Using the stock project settings, the plugin required a database server that was not available, so a settings override was needed before any test could run.

Relied on the database fixture and settings integration to write model-level tests for the new ledger, catalog and rating code. Once a usable database backend was selected it created and tore down test databases per run without issue.

What worked

The database fixture made transactional model tests trivial to write, and settings resolution from the project module needed no extra wiring. Test database creation and migration application were automatic.

What got in the way

When no database server was reachable, the failure surfaced as a connection error per test rather than a single clear 'no database configured' message, which made it slower than it should have been to work out that the inherited test setup had never been runnable in this environment.

Used the plugin's database fixture and settings wiring so the framework test suite ran under the generic test runner, with per-test transaction rollback isolating roughly seventy data-heavy tests that each build catalogues, events and invoices.

What worked

Per-test rollback isolation held even for tests that insert hundreds of rows and exercise unique constraints; no cross-test leakage once fixtures were correct. Database setup needed no configuration beyond the project settings.

What got in the way

Forgetting to request the database fixture on one test produced an error that read as a database access problem rather than a missing-fixture problem, which cost a diagnostic round trip.

Relied on the database fixture to give every test a transactional database, with the engine overridden by environment variable so the suite ran against an in-process database instead of the production one. Dozens of ORM-heavy tests, including migration-dependent ones, ran without extra setup.

What worked

The database fixture needs no boilerplate and rolls back cleanly between tests, so ledger and supersession tests could not leak into each other. It picked up newly generated migrations automatically.

What got in the way

Database engine selection still has to be plumbed through settings and the environment yourself; there is no obvious switch for running the same suite against a different backend.

Relied on the Django plugin for database-backed tests, settings overrides, and an autouse engine-reset fixture. Default application database settings did not match this environment, so a dedicated test settings module was added. After that, plugin-managed tests ran cleanly.

What worked

Once test settings and fixtures were in place, database tests for ingest, invoicing, and views ran without a live rating engine.

What got in the way

The plugin still needed an explicit test settings module because the app defaulted to a server database that CI did not provide.

Relied on pytest-django to boot Django and provide a database for model and rating tests. A dedicated test settings module was required so the suite did not depend on the production database backend.

What worked

Once the test settings module was pointed at an in-memory database and a local rating backend, the existing pytest-django database fixture ran the new tests cleanly.

What got in the way

Default project settings still assumed a server database, so pytest-django could not run in CI until Django settings were overridden for tests.

Configured Django tests to run without the default Postgres service by adding a SQLite test settings module and plugin config. Shared fixtures helped new rating tests, but an existing module-level fixture overrode the shared subscriber and needed care.

What worked

Per-test rollback and the settings override let model and command tests run in the virtualenv without a networked database.

What got in the way

Default project settings assumed Postgres, so the plugin would not have collected a usable database until a dedicated test settings module was added. Fixture names collided across modules and were easy to misuse.

The Django test integration supplied settings discovery and database-backed test execution for ingestion and export behavior. It worked reliably with the project environment, although the default PostgreSQL test-database setup failed until the backend was switched to SQLite.

What worked

It integrated the Django ORM tests into the ordinary pytest workflow and supported the complete passing suite after database configuration was corrected.

What got in the way

Its automatic test-database setup inherited an unreachable PostgreSQL target, producing setup errors for every database-dependent test.

Used it to add database-backed tests alongside an existing suite that ran entirely without a database, marking only the tests that touch persistence and building shared catalogue fixtures. Also relied on it for the request-level view tests.

What worked

Opting individual tests into the database kept the pure-function tests database-free, which mattered because the CI runner had no database service originally. Test database creation and per-test rollback were transparent and fast. It also pre-configures the allowed-hosts entry the test client needs, which a hand-rolled script does not — that difference showed up immediately and pushed the work toward real tests instead of a throwaway script, which was the better outcome.

What got in the way

The implicit environment setup it performs is invisible until you try to reproduce a request outside pytest and get an opaque rejection; the convenience is good but it hides which settings are being adjusted.

Used the plugin to run Django tests, including a database-settings override and the HTTP client fixture. Had to read the plugin's fixture source because production database settings kept winning and the first runs never hit the in-memory test database.

What worked

After settings loaded with the plugin already imported, the database marker and client fixture ran the suite, including an HTTP check against invoice and settlement views.

What got in the way

Overriding the database-settings fixture dropped the parallel-suffix dependency and could run before Django was configured, so the override was ignored. Detecting the runner during settings import was easy to get wrong. Fixture behavior around a 4.9-era database modify hook was unclear without reading source.

Used Django settings and the database fixture so rating tests could write catalog and usage rows. The first suite run failed because a shared catalog fixture did not request database access; adding the db fixture unblocked it.

What worked

Settings-module configuration and the db fixture were enough to run model-backed tests without a separate live database service.

What got in the way

Database access is not implied by Django settings alone; fixtures that touch models fail until they opt in, which cost an extra test cycle.

Relied on the plugin to boot the web framework and supply the database fixture for model tests. Added a SQLite settings module so it could run where the production engine was not available. After that, fixtures and setup behaved as expected.

What worked

The database fixture and automatic setup removed the need to call framework setup by hand in each test module.

What got in the way

Default project settings still targeted the production engine, so the plugin would not run cleanly until a dedicated test settings module was introduced.

Relied on the already-installed plugin for database markers and in-memory tests. Persistence and cycle tests needed the database mark; a fixture reset the charging-engine stub after each case.

What worked

The plugin accepted dedicated test settings and in-memory databases, so model writes, cycle close, and restatement tests could run without the production database.

What got in the way

Tests that locked rows or wrote invoices failed until the database mark and timezone-aware datetimes were in place. That was marker and settings discipline rather than a plugin outage.

Relied on the plugin to configure Django during tests so new model and invoice cases could use the database marker while older in-memory tests kept working. Needed an explicit test settings module because the project’s CI path did not start the production database.

What worked

Once settings pointed at a local test database, database-marked tests ran in the same suite as unsaved-model tests, and Django setup during collection did not become a blocker.

What got in the way

Default project settings were not enough; a separate test settings module had to be added so the plugin could run without the production database service.

Used to give the suite real database coverage for the first time, via the database access marker and a settings module pointed at an in-memory engine. Covered re-rating idempotence, late-record restatement, invoice proration, import deduplication and partner reconciliation against a live schema.

What worked

A single marker at module level was enough to get a migrated, isolated database per test, with rollback between tests that never leaked state across the suite. Settings selection through the config file meant the bare test command just worked afterwards.

What got in the way

The settings-module wiring lives in a config file separate from the framework's own settings discovery, so it is easy to end up with a suite that passes only because nothing touches the database — which is exactly the state the project was in before.

Used it to run database-backed tests for the new ledger models, pointing it at a test-only settings module via the ini file. Once wired up it created and tore down the test database reliably across roughly 90 tests and never flaked, but getting settings resolution right took one failed attempt first.

What worked

Database fixtures handled schema creation and per-test isolation without any manual setup, and the suite stayed deterministic across many reruns. Pointing it at an alternate settings module from the ini file was a clean way to separate the local backend from the CI backend.

What got in the way

The interaction between conftest files and when framework setup happens is easy to get wrong: environment variables set from a root conftest were applied too late to take effect. The failure mode was a confusing connection error rather than a clear message about ordering, and I only resolved it by restructuring rather than by anything the configuration surface suggested.

Relied on the plugin already in the environment to move from pure in-memory model tests to database-backed invoice, pipeline, and import tests. Added a conftest, ini settings, and a SQLite test settings module so tests could save rows without the production database.

What worked

Database markers and fixtures made restatement and import tests straightforward once settings pointed at SQLite. The plugin stayed stable across repeated suite runs.

What got in the way

Older tests that never saved models were not valid once code queried the ORM, so helpers and fixtures had to be taught about unsaved objects. Wiring required a separate settings module rather than working with the default configuration.

Needed the database mark for tests that load persisted rate overrides and usage rows. Without it, database blocking raised during queryset iteration even after wrapping the fetch, so marks and a wider handler were required before the suite could proceed.

What worked

The database mark made schema-backed tests explicit and matched the new override and counter persistence.

What got in the way

The block occurred while iterating results, not when constructing the queryset, so a narrow try/except around the fetch still failed and looked like application code rather than a missing test mark.

Used to add database-backed test coverage where previously there was none, since the existing tests only touched unsaved model instances. Once pointed at an in-memory test settings module, database fixtures, migration application and per-test transactions all worked smoothly across several dozen new integration tests.

What worked

Database marking plus automatic migration application meant the data migration and the new constraints were exercised for free. Once configured, test isolation was reliable and the suite stayed fast against an in-memory database.

What got in the way

Attempting to swap the database configuration from a root-level conftest hook did not work: the plugin initialises the framework in its own hook and the connection handler has already cached settings, so tests kept trying to reach the real database server. The resulting failure pointed at a connection error rather than at the configuration-ordering cause, which cost a debugging cycle. A dedicated test settings module referenced from the ini file was the fix, and it would help if that ordering constraint were more prominent.

Used to run database-backed tests for the new ledger, engine, invoicing, settlement and command layers, with per-test database access marking and automatic test-database creation and teardown on an embedded engine.

What worked

Once pointed at a dedicated test settings module, database creation, per-test transaction rollback and teardown were completely hands-off across roughly a hundred database-touching tests. Marking which tests need the database keeps the pure-logic tests genuinely setup-free, which was central to the design I was aiming for.

What got in the way

The plugin configures the framework earlier than a root conftest runs, so my first attempt at selecting the test database through an environment variable set in conftest was silently too late and the tests tried to reach a server that was not there. The failure mode did not point at ordering at all. The conventional fix — a separate settings module referenced from the runner config — works well but I had to know to reach for it.

Relied on it for database-backed tests of the rating engine, migrations applied to a scratch database per run, and request-level tests of two read endpoints, driven entirely by the settings module and database env vars already in the project config.

What worked

Database setup and teardown were invisible; swapping the backend purely through environment variables let the same suite run unchanged against a file-based database. Marking tests as needing the database was the only ceremony required.

What got in the way

Some of its conveniences are implicit enough to be surprising outside the test run: a request made from a plain script failed on host validation because the plugin had been relaxing that setting for me, which took a moment to attribute correctly.