Testing Strategy
PrimeCal uses layered tests so we can prove the smallest useful unit first, then scale up to integration, e2e, and infrastructure-aware checks only when risk justifies the cost.
Working rules
- Prefer the cheapest test layer that can prove the behavior.
- Do not delete failing coverage just to get green. Fix code, update valid expectations, or explicitly retire obsolete behavior with documentation.
- Reuse existing test helpers and Jest configs instead of inventing parallel harnesses.
- When dependency upgrades change runtime behavior, treat the fallout as real repair work.
Command map
Fast repo-level checks
npm run ci:qualitynpm run ci:i18nnpm run docs:checknpm run docs:portal:build
Backend core
npm --prefix backend-nestjs run test:unitnpm --prefix backend-nestjs run test:securitynpm --prefix backend-nestjs run db:audit:queries
Backend integration and e2e
npm --prefix backend-nestjs run test:integrationnpm --prefix backend-nestjs run test:e2e
MCP-specific coverage
npm --prefix backend-nestjs run test:mcp:integrationnpm --prefix backend-nestjs run test:mcp:securitynpm run test:e2e:mcp-browser
Frontend
npm --prefix frontend run lintnpm --prefix frontend run test:unitnpm --prefix frontend run test:integrationnpm --prefix frontend run build:typecheck
Test layers
1. Unit
Use unit tests for isolated business rules, guards, DTO validation behavior, mapper logic, and UI utilities. This is the default layer for new logic.
2. Security-focused backend tests
Use test:security for cross-tenant isolation, auth edge cases, secure headers, rejection paths, and validation failures that should stay locked down.
3. Integration
Use test:integration when the behavior depends on Nest modules, persistence, real request flow, or testcontainers-managed services.
4. MCP integration and protocol conformance
PrimeCal treats MCP as a supported product surface. The MCP integration lane validates:
- initialization and session flow
- tool and resource discovery
- scoped agent access
- meeting URL and event search behavior
- protocol-safe error responses
5. Backend e2e
Use backend e2e to prove end-to-end request flow through the real HTTP surface when the integration layer is not enough.
6. Frontend integration and browser e2e
Frontend integration tests cover component and feature interaction without external infrastructure. Browser e2e is reserved for higher-risk flows because it is slower and more environment-sensitive.
CI contract
Required lanes
These lanes are the default CI contract for pull requests to main and for protected pushes:
- quality
- i18n
- backend-core
- backend-integration
- backend-e2e
- mcp-integration
- mcp-security
- frontend-unit
- frontend-integration
- docs-quality
Conditional lanes
dependency-audit: required whenever manifests or lockfiles change, and on scheduled/manual runsweb-e2e,mobile-e2e,api-smoke,load, andZAP: used for heavier verification onmain, scheduled runs, or manual dispatch
Docs-only optimization
Docs-only changes skip the full app matrix but still run docs quality. This keeps markdown and portal work fast without weakening product validation on real code changes.
Local verification order
Use this order before asking CI to prove the same thing:
npm run ci:qualitynpm run ci:i18n- backend unit and security
- backend integration and e2e
- MCP integration and security
- frontend lint, unit, integration, and build
- docs checks and portal build
- dependency audits when dependencies changed
When to update tests
Update tests when:
- the user-facing or API contract changed intentionally
- dependency upgrades changed the correct behavior
- docs previously promised coverage that the repo should still provide
Do not weaken assertions just because a suite is currently noisy. If the old expectation is wrong, update it to the new contract and document why.