Running the Test Suite

Running the Test Suite

cd backend
pip install -r requirements-dev.txt
pytest

Covers the pure logic — the RFC-driven DNS checkers (DMARC subdomain inheritance, SPF conditional mode, MTA-STS wildcard matching, DANE's DNSSEC requirement), domain matching, and rating computation — mocking the DNS layer rather than hitting real resolvers, so it's fast and deterministic. Several of these tests exist specifically because the logic they cover had a real bug found and fixed during development; they're regression tests as much as documentation of the intended behavior.

Row-level security — the multi-tenancy boundary — has its own integration suite (backend/tests/test_rls.py) that runs against a real Postgres as the non-owner dmarc_app role (the one FORCE ROW LEVEL SECURITY binds, and the one the app connects as), so it proves the same isolation that protects production rather than mocking it. See Multi-Tenancy & Row-Level Security for what it checks.

Those tests are gated on a TEST_DATABASE_URL env var; without it they skip, so the default pytest run stays fast and needs no database. To run them locally:

docker run -d --name dmarc-test-db -e POSTGRES_PASSWORD=postgres \
    -e POSTGRES_DB=dmarc_test -p 55432:5432 postgres:16-alpine
TEST_DATABASE_URL=postgresql+asyncpg://postgres:postgres@localhost:55432/dmarc_test pytest

CI (.github/workflows/ci.yml) sets TEST_DATABASE_URL against a Postgres service container, so the RLS suite runs on every push/PR alongside the unit tests and the frontend build. Still not covered by automated tests: the full report-ingestion pipeline and the HTTP routers — those are still verified by exercising the deployed code path against real data (see the Roadmap).

New Alembic revisions go in backend/alembic/versions/, hand-written rather than relying purely on autogenerate — see any existing migration for the pattern (including the row-level-security policy that has to accompany any new tenant-owned table).

---

← Contributing & Development · Home