Django Backend Testing
Validate behavior and architectural boundaries against approved contracts.
Required Context
Read AGENTS.md, docs/architecture/backend-validation-plan.md, docs/architecture/api-contract.md, docs/architecture/security-contract.md, docs/architecture/backend-implementation-contract.md, docs/architecture/backend-contract-manifest.json, .codex/references/backend-testing.md, .codex/references/module-documentation.md, and .codex/checklists/backend-validation.md.
Workflow
- Map every manifest invariant and endpoint ID to the correct implementation and test layer.
- Test DTO structure and explicit Mappers without persistence.
- Test Services with fake Repository contracts and no database or HTTP client.
- Test Repositories against the database, including ownership, queries, transactions, and persistence.
- Test Controllers through the API boundary, including authentication, permissions, statuses, errors, and response shape.
- Add every exact positive/negative
test_* function required by the manifest, including zero/one/multiple cardinality and foreign-tenant cases where listed.
- Run every required manifest validation, Django checks, pending-migration checks, the full test suite, and the architecture scanner.
- Verify every authored test module has a meaningful opening docstring.
- Record exact commands, contract evidence, failures, skipped surfaces, unavailable dependencies, and limitations.
Integrity Rules
- Do not add
skip, xfail, mocks, retries, or weakened assertions solely to obtain green output.
- Do not use the database in Service tests or mock the database in Repository tests.
- Do not treat passing tests as architectural approval; the architect/auditor owns final approval.
- Do not conceal unavailable services, flaky behavior, or validation gaps.
- Do not claim a required integration/browser validation passed when it was deferred or simulated.
Finish only when coverage traces to contracts, boundaries are exercised, and evidence distinguishes passing, failing, and untested behavior.
1---2name: django-backend-testing3description: Add, organize, run, and assess Django backend tests and architecture validation for an approved implementation. Use for DTO, Mapper, Service, Repository, Controller/API, permission, security, migration, integration, and boundary-scanner coverage. Do not use to weaken assertions, conceal failures, or change approved behavior merely to make tests pass.4---56# Django Backend Testing78Validate behavior and architectural boundaries against approved contracts.910## Required Context1112Read `AGENTS.md`, `docs/architecture/backend-validation-plan.md`, `docs/architecture/api-contract.md`, `docs/architecture/security-contract.md`, `docs/architecture/backend-implementation-contract.md`, `docs/architecture/backend-contract-manifest.json`, `.codex/references/backend-testing.md`, `.codex/references/module-documentation.md`, and `.codex/checklists/backend-validation.md`.1314## Workflow15161. Map every manifest invariant and endpoint ID to the correct implementation and test layer.172. Test DTO structure and explicit Mappers without persistence.183. Test Services with fake Repository contracts and no database or HTTP client.194. Test Repositories against the database, including ownership, queries, transactions, and persistence.205. Test Controllers through the API boundary, including authentication, permissions, statuses, errors, and response shape.216. Add every exact positive/negative `test_*` function required by the manifest, including zero/one/multiple cardinality and foreign-tenant cases where listed.227. Run every required manifest validation, Django checks, pending-migration checks, the full test suite, and the architecture scanner.238. Verify every authored test module has a meaningful opening docstring.249. Record exact commands, contract evidence, failures, skipped surfaces, unavailable dependencies, and limitations.2526## Integrity Rules2728- Do not add `skip`, `xfail`, mocks, retries, or weakened assertions solely to obtain green output.29- Do not use the database in Service tests or mock the database in Repository tests.30- Do not treat passing tests as architectural approval; the architect/auditor owns final approval.31- Do not conceal unavailable services, flaky behavior, or validation gaps.32- Do not claim a required integration/browser validation passed when it was deferred or simulated.3334Finish only when coverage traces to contracts, boundaries are exercised, and evidence distinguishes passing, failing, and untested behavior.
viniciusjsdev