Skip to main content

Testing & Reliability

LusterCMS includes a comprehensive automated testing suite designed to ensure security, data isolation, and reliability—particularly for multi-tenant SaaS deployments.

What We Test​

Our test suite covers all critical areas of the platform:

AreaWhat we verify
Multi-tenant isolationOrganization registration, org context switching, "everything down, nothing up" access rules
AI & BlueBird isolationKnowledge retrieval scoped to org, Q&A context boundaries, billing isolation, cross-org attack prevention
Tenant admin operationsAdmin/Agency wizards, organization CRUD, credit allocation, theme and demo content provisioning
WebSocket & collaborationJWT authentication, room naming with org scope, cross-org isolation, secure error handling
RBAC & sidebar visibilityPermission matrix enforcement, plugin-based sidebar filtering, no upward access
Kubernetes & loggingHealth checks, rolling updates, HPA configuration, structured logs with org_id

Automation & Coverage​

The platform maintains 300+ automated tests spanning multiple testing strategies:

  • E2E tests – simulate full user flows across tenant boundaries
  • Integration tests – verify database routing, API responses, and middleware behavior
  • Unit tests – cover individual services, resolvers, and security functions

Key focus areas include:

  • Multi-tenant registration and provisioning flows
  • AI assistant isolation and billing attribution
  • Admin and Agency wizard workflows
  • WebSocket authentication and room isolation
  • Permission matrix and role-based access control

All tests run automatically in CI before any deployment.

Golden Rules for Changes​

When contributing to LusterCMS, follow these principles to maintain security and reliability:

1. Every change needs tests​

New features and behavior changes must include corresponding tests. Bug fixes should add regression tests to prevent recurrence.

2. Use permission codes, not role names​

Access control logic must check permission codes (e.g., content.edit, media.upload), never role names directly. This ensures consistent enforcement across the permission matrix.

# ✅ Correct
if resolver.has_permission("content.edit"):
    ...

# ❌ Wrong
if user.role == "admin":
    ...

3. Always use org-scoped database access​

All tenant data operations must use the tenant adapter to maintain isolation:

# ✅ Correct - uses tenant-aware database
db = get_db_for_tenant_data(info)

# ❌ Wrong - bypasses tenant isolation
db = info.context["db"]

4. Respect "everything down, nothing up"​

Use get_allowed_org_ids() for any query that touches multiple organizations. This ensures:

  • Superadmins can see all organizations (or filter to a selected subtree)
  • Agency admins see only their managed organizations
  • Organization users see only their own organization
  • No user can ever access data from organizations above them in the hierarchy

CI & Observability​

Continuous Integration​

All tests run automatically on every pull request and before deployment:

  • Test failures block merges to protected branches
  • Coverage reports track test completeness
  • Security-focused tests have explicit assertions for isolation rules

Logging & Monitoring​

Production deployments include structured logging with tenant context:

  • Promtail collects logs from all pods
  • Loki indexes logs with org_id as a label
  • Grafana dashboards enable filtering by organization

Example query to see requests for a specific organization:

{service="backend"} | json | org_id="42"

This enables rapid debugging of tenant-specific issues without accessing other organizations' data.