Mock PostgreSQL dependencies in unit tests to enable database-free test runs #281

New issue

Closed

opened 2026-05-10 19:07:29 +00:00 by jflory7 · 0 comments

jflory7 commented

2026-05-10 19:07:29 +00:00

Owner

Currently 38 of 68 unit tests fail when run outside the Podman Compose environment because they attempt to connect to a PostgreSQL instance at hostname db. This means the test suite cannot pass in CI without spinning up a PostgreSQL service container, and local development requires a running database for any test feedback.

The goal is to mock the database layer so that all unit tests pass without a live PostgreSQL connection. This would:

Simplify the CI pipeline (remove the db service dependency from the test job)
Enable faster local development feedback (poetry run pytest works anywhere)
Reduce CI resource usage and execution time

The test settings file (happinesspackets/settings/tsting.py) currently inherits the PostgreSQL database configuration from dev.py. Tests that hit the database include model creation via factory-boy factories (MessageModelFactory, BlacklistedEmailFactory), view tests that query the ORM, and form validation tests.

Possible approaches:

Use SQLite as the test database backend (simplest, may surface minor dialect differences)
Use unittest.mock to mock ORM queries in view/form tests
Use pytest-django's django_db marker with an in-memory SQLite database configured in tsting.py

Related: the CI workflow (.forgejo/workflows/ci.yml) currently provisions a postgres:15 service container for the test job that could be removed once this is resolved.

Currently 38 of 68 unit tests fail when run outside the Podman Compose environment because they attempt to connect to a PostgreSQL instance at hostname `db`. This means the test suite cannot pass in CI without spinning up a PostgreSQL service container, and local development requires a running database for any test feedback. The goal is to mock the database layer so that all unit tests pass without a live PostgreSQL connection. This would: - Simplify the CI pipeline (remove the `db` service dependency from the test job) - Enable faster local development feedback (`poetry run pytest` works anywhere) - Reduce CI resource usage and execution time The test settings file (`happinesspackets/settings/tsting.py`) currently inherits the PostgreSQL database configuration from `dev.py`. Tests that hit the database include model creation via `factory-boy` factories (`MessageModelFactory`, `BlacklistedEmailFactory`), view tests that query the ORM, and form validation tests. Possible approaches: - Use SQLite as the test database backend (simplest, may surface minor dialect differences) - Use `unittest.mock` to mock ORM queries in view/form tests - Use `pytest-django`'s `django_db` marker with an in-memory SQLite database configured in `tsting.py` Related: the CI workflow (`.forgejo/workflows/ci.yml`) currently provisions a `postgres:15` service container for the test job that could be removed once this is resolved.