Course outline

01 · Introduction to the Meridian Platform3/3

02 · Workspace Layout, Design Principles, and the Platform Library5/5

03 · The Data Layer4/4

04 · Identity Service: HTTP API Layer4/4

05 · Authentication and Authorization4/4

06 · The Gateway Service2/2

07 · Testing Strategy5/5

08 · Caching and Rate Limiting3/3

09 · Background Processing3/3

10 · File Storage2/2

11 · Event-Driven Communication3/3

12 · Resilience Patterns2/2

13 · Observability3/3

14 · Advanced PostgreSQL3/3

15 · API Versioning and the Platform Contract2/2

16 · Containerization and Deployment4/4

17 · CI/CD Pipeline2/2

18 · Security Hardening2/2

19 · Capstone: System Integration2/2

20 · Retrospective2/2

Stage 7 · Master

Testing Strategy

Unit and Table-Driven Tests

The first Meridian unit tests target the code that already exists: libs/platform helpers and each service's small config loader.

15 min readMeridian: A Multi-Tenant Go PlatformMaster

Why Unit Tests Come First

Meridian is still in the scaffolding phase. Every service binary builds, starts, and exposes only /healthz. That sharply limits what can be tested today, but it does not eliminate unit-test value. The code that already exists in libs/platform and in each service's internal/config package defines cross-service conventions; those conventions should be pinned down before the first real handler depends on them.

Layer	What exists now	Best test shape
libs/platform/config	config.Env fallback helper	Dense table-driven unit tests
libs/platform/logging	Level parsing and service-tagged slog logger	Unit tests over level inputs and logger output
libs/platform/errors / response	Platform Contract wire types	Unit tests over constructors and JSON shape
libs/platform/tenancy	X-Tenant-Id constant and context helpers	Unit tests for context round-trips
apps/*/internal/config	Per-service env mapping	Table-driven config-loader tests

Real Unit-Test Targets Today

Files in this step— The first useful tests touch only code that is already present in meridian.

libs/platform/config/config_test.gocreate

Responsibility: Proves that config.Env returns the environment value when set and the fallback when unset or empty.

Why now: Every service config loader depends on this helper. A bug here would cascade into all four services at startup.

Connects to: Covers libs/platform/config/config.go, the first shared helper imported by apps/gateway and the three domain services.

libs/platform/tenancy/tenancy_test.gocreate

Responsibility: Asserts that WithTenantID stores the tenant UUID in context and TenantIDFromContext reads it back safely.

Why now: Tenant propagation is the shared vocabulary for the entire platform. The helper must be boring and correct.

Connects to: Pins down the X-Tenant-Id propagation model described in docs/architecture/services.md.

apps/gateway/internal/config/config_test.gocreate

Responsibility: Exercises Load() against GATEWAY_PORT, LOG_LEVEL, and the three downstream service URLs.

Why now: The gateway is the only service that knows every downstream address. A bad default here breaks local development immediately.

Connects to: Covers apps/gateway/internal/config/config.go and the .env.example values documented in the reference repo.

Gotable-driven-tests-for-libs/platform/config.env.go

26 linesLn 1, Col 1Go

The important property is not complexity. It is repeatability. The same helper feeds every later Config.Load() function across the workspace, so a tiny table buys disproportionate safety.

Gounit-test-for-libs/platform/tenancy-context-helpers.go

12 linesLn 1, Col 1Go

This is the simplest possible proof of the platform's tenant vocabulary. Once handlers and repositories arrive, richer tests build on top of this primitive rather than re-testing context mechanics everywhere.

Table-Driven Examples

Go's table-driven style fits Meridian's current codebase because the rules are small, repetitive, and mostly input/output oriented. config.Env, logging level parsing, errors.New().WithTraceID(), and response.OKWithMeta() are all better expressed as short test tables than as one-off bespoke tests. The structure keeps edge cases visible without turning simple packages into noisy test suites.

No fabricated handler tests

The current repo has no tenant resolver middleware, no CRUD handlers, and no repository interfaces yet. This chapter therefore keeps its concrete examples on the code that does exist, and treats future handler tests as patterns for later chapters rather than present-tense implementation.

Service Config Loaders

Each service's internal/config.Load() function is another strong unit-test target because it translates .env.example into process-local settings. The gateway loader is the richest case today because it maps GATEWAY_PORT plus the three downstream service URLs. identity-service, community-service, and billing-service have a smaller surface, but the pattern is identical and should stay identical as database DSNs, Redis settings, and Kafka settings are added later.

Gotable-driven-test-for-apps/gateway/internal/config.load.go

14 linesLn 1, Col 1Go

Nothing about this test is glamorous. That is exactly the point. Configuration tests should be fast, explicit, and hard to misunderstand in review.

Terminal — meridian repo root

$go test ./libs/platform/...

// Runs the shared library unit tests that are fully justified by the current scaffold.

$go test ./apps/gateway/internal/config ./apps/identity-service/internal/config ./apps/community-service/internal/config ./apps/billing-service/internal/config

// Exercises every concrete Config.Load() package without pretending that richer handler packages already exist.

$go test ./apps/gateway/... ./apps/identity-service/... ./apps/community-service/... ./apps/billing-service/...

// Build-and-test pass across the existing service modules once the foundational unit tests are in place.

The Decision

The first Meridian unit tests target libs/platform and internal/config because those are the packages that already contain reusable behavior.
Table-driven tests are the default style for config, logging, response, error, and tenancy helpers because the behavior is compact and repetitive.
No lesson example assumes business handlers, repositories, or domain entities that do not yet exist in the scaffold.
Later service-specific tests build on these conventions rather than replacing them.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.