Register all active platform services and base features in core DB so admin can manage them, add delivery/hospitality/sports-center backend phases, update apps catalog and production deploy tooling. Co-authored-by: Cursor <cursoragent@cursor.com>
2.0 KiB
2.0 KiB
Testing Strategy
Required Layers
| Layer | Purpose |
|---|---|
| Unit | Pure domain logic, validators, mappers, specifications, policies |
| Service / Command / Query | Business rules with DB/fakes; read-side without write side-effects |
| Repository | Query correctness, tenant filters, soft-delete, page/filter/sort/search |
| API | HTTP contracts, authz, status codes, OpenAPI smoke when pattern exists |
| Integration | Multi-component flows (onboarding, OTP, SSO handoff) |
| Migration | Upgrade/downgrade smoke on clean DB; seeds when required |
| Tenant | Cross-tenant isolation negatives |
| Performance | Hot entitlement/resolve/list paths as needed |
| Security | Auth bypass attempts, token scope checks |
| Architecture | Boundary/layering rules (service suites) |
| Documentation validation | Links, registry completeness, DoD/handover for the phase |
| Permission | Privileged route denial cases |
Rules
- New behavior ships with tests in the same phase.
- Tenant tests must include at least one cross-tenant denial case for new tenant-scoped APIs.
- Do not rely on production data for assertions.
- Prefer deterministic time/OTP fakes.
- Phase is incomplete if tests fail or are absent for claimed deliverables.
- CRUD-only coverage without domain-rule tests is insufficient when business rules exist (definition-of-done.md).
- Architecture, security, and documentation validation are required for service/module implementation phases (testing-template.md).
Commands (current)
cd backend/core-service
pytest -q
cd backend/services/identity-access
pytest -q