Skip to main content
Was this helpful?

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:quality
  • npm run ci:i18n
  • npm run docs:check
  • npm run docs:portal:build

Backend core

  • npm --prefix backend-nestjs run test:unit
  • npm --prefix backend-nestjs run test:security
  • npm --prefix backend-nestjs run db:audit:queries

Backend integration and e2e

  • npm --prefix backend-nestjs run test:integration
  • npm --prefix backend-nestjs run test:e2e

MCP-specific coverage

  • npm --prefix backend-nestjs run test:mcp:integration
  • npm --prefix backend-nestjs run test:mcp:security
  • npm run test:e2e:mcp-browser

Frontend

  • npm --prefix frontend run lint
  • npm --prefix frontend run test:unit
  • npm --prefix frontend run test:integration
  • npm --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 runs
  • web-e2e, mobile-e2e, api-smoke, load, and ZAP: used for heavier verification on main, 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:

  1. npm run ci:quality
  2. npm run ci:i18n
  3. backend unit and security
  4. backend integration and e2e
  5. MCP integration and security
  6. frontend lint, unit, integration, and build
  7. docs checks and portal build
  8. 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.