Skip to content

Integration Testing

Document ID: TEST-002
File Path: docs/15-testing/integration-tests.md
Version: 1.0.0
Status: Draft
Owner: Quality Engineering Team
Last Updated: 2026-06-27


This document defines integration testing — verifying that services work correctly against real datastores and neighboring services, catching issues that unit tests (with mocks) cannot.


BoundaryExamples
Service ↔ datastoreMemory Engine ↔ Postgres + Qdrant
Service ↔ serviceAgent Runtime ↔ LLM Gateway ↔ Tool Runtime
API contractsEndpoint behavior, errors, pagination, idempotency
Event flowsplugin.*, execution.* over NATS

Integration tests run against ephemeral real backends, started via Docker Compose (Postgres, Redis, Qdrant, NATS, MinIO) or Testcontainers:

spin up compose (core profile) → migrate → seed → run tests → tear down

This matches the team self-host topology, so tests exercise the real wiring.


  • LLM providers are replaced by a recorded/fake provider behind the LLM Gateway so tests are deterministic and free of external cost.
  • A small suite of live provider smoke tests runs separately (gated, optional) to catch real-provider drift.

Each external contract has tests asserting the documented behavior:

Contract tests guard against accidental breaking changes.


  • Each test run uses an isolated tenant/namespace; tests assert no cross-tenant leakage (a hard requirement — authorization).
  • Fixtures are created and torn down per test/suite to avoid coupling.

For async flows, tests subscribe to the Event Bus and assert the expected *.completed/*.failed events occur, rather than sleeping.


Database migrations are tested forward (and where supported, backward) to ensure safe upgrades.


Integration tests run on PRs (after unit) against a fresh stack and must pass to merge (CI pipeline).




VersionDateDescription
1.0.02026-06-27Initial Integration Testing specification