Patterns on MinimumCD Practice Guide

API Provider

Mon, 01 Jan 0001 00:00:00 +0000

A backend service that exposes an HTTP/gRPC/GraphQL API and owns its own data. No outbound calls to other services in your control.

What needs covered

Layer	Concern	Test type
Domain logic	Business rules, invariants, state transitions	Solitary unit tests
Module collaboration	Validators + repositories + domain working together	Sociable unit tests
Persistence adapter	Query correctness, transaction boundaries, migrations against the real DB engine	Adapter integration tests (testcontainers running production engine and version)
Assembled component	Routing, validation, business logic, and persistence wired together through the controller layer	Component tests with persistence either real (testcontainers) or doubled (in-memory repository)
Served API	What downstream consumers depend on	Provider-side contract tests

Positive test cases

Common cases to consider, not an exhaustive list. Drop items that don’t apply and add ones the pattern doesn’t mention but your component needs.

API Consumer

Mon, 01 Jan 0001 00:00:00 +0000

Same as API provider, plus outbound HTTP/gRPC calls to services the team does not own (or does own but deploys independently). This is the most failure-prone pattern in distributed systems and gets the most testing attention.

What needs covered

Everything from the API provider pattern, plus:

Layer	Concern	Test type
Outbound HTTP client	Request shape, response parsing, status code handling, header propagation, timeout enforcement	Adapter integration tests (against WireMock or, periodically, the real downstream)
Consumed API contract	The fields and status codes the consumer depends on	Consumer-side contract tests
Resilience under degraded dependencies	Retries, circuit breaking, backoff, fallback, partial-failure compensation	Component tests with fault-injecting client doubles
Composite behavior	The service still returns useful responses when downstreams misbehave	Component tests

Positive test cases

Common cases to consider, not an exhaustive list. Drop items that don’t apply and add ones the pattern doesn’t mention but your component needs.

Scheduled Job

Mon, 01 Jan 0001 00:00:00 +0000

A job that runs on a cron, queue, or external scheduler. Reads from data sources, writes reports or updates state. Often has no inbound API surface. The entrypoint is the scheduler.

This pattern has two test design challenges that the API provider and API consumer patterns don’t have: time and data volume.

What needs covered

Layer	Concern	Test type
Pure transformation logic	The data calculation itself, with no I/O	Solitary unit tests
Source and sink adapters	Reading from sources, writing to sinks: protocol correctness, error mapping	Adapter integration tests against real source/sink containers or WireMock
Job orchestration	Idempotency, partial failure recovery, checkpointing, locking, time-window logic	Component tests through the job’s invocation entrypoint, with client doubles, source/sink doubles, and an injected clock
Process startup	Exit codes, signal handling, configuration loading, real environment wiring	Deployed-binary tests that invoke the real artifact
Scheduling integration	The scheduler triggers the right entrypoint with the right arguments, environment, secrets, and concurrency settings	Out-of-band integration check against the real scheduler in a non-prod environment
Observability	Job ran, succeeded/failed, duration, records processed, error count	Assertions in component tests

Process startup matters more here than for an API service, because scheduled jobs typically have non-trivial startup behavior (config loading, secret resolution, lock acquisition) that a component test with the SUT in-memory can bypass. The right shape is many component tests for behavior, plus one or two tests that invoke the actual deployed binary the scheduler will invoke.

User Interface

Mon, 01 Jan 0001 00:00:00 +0000

A UI that renders data and accepts user interaction. Talks to one or more backend APIs.

What needs covered

Layer	Concern	Test type
Pure rendering	Component renders given props/state	Solitary unit tests
Component composition	Composed components wire correctly	Sociable unit tests
Feature behavior	A flow (login, checkout, search) works through the rendered DOM with the backend stubbed at the network layer	Component tests driven by Playwright with the team’s unit-testing framework as the runner
Backend contract	What the UI sends and expects from each backend endpoint	Consumer-side contract tests
End-to-end happy paths	A small number of critical journeys against real backends	E2E tests, post-deploy
Visual regression	The UI looks right	Snapshot or visual diff tests
Accessibility	The UI works for assistive tech and keyboard users	Assertions in component tests + automated WCAG scanning

UI component tests run in a real browser engine (Chromium, Firefox, WebKit) driven by Playwright, with the team’s existing unit-testing framework (Vitest, Jest, or whatever is already in the project) as the runner. In-memory renderer shortcuts like JSDOM are rejected: they trade accuracy for speed and produce false greens around layout, focus, event timing, Intersection Observer, and animations - exactly the surface where UI bugs live. Playwright’s headless Chromium starts in milliseconds and runs the suite fast enough to use as the default. Backends are stubbed at the network layer with page.route so the same fixtures drive component tests today and end-to-end smoke tests later.

Event Consumer

Mon, 01 Jan 0001 00:00:00 +0000

A consumer of messages from Kafka, SQS, RabbitMQ, Pub/Sub, or similar. Reads messages, processes them, often updates state and produces downstream messages. The “public interface” is the topic or queue and the schema of messages on it.

This pattern has problems the API provider and API consumer patterns don’t have: ordering, replay, poison messages, dead-letter queues, and delivery semantics (at-most-once, at-least-once, exactly-once-with-effort).

What needs covered

Layer	Concern	Test type
Message handler	Pure transformation per message	Solitary unit tests
Idempotency	Same message twice produces the same effect	In-process component tests
Poison message handling	Malformed message goes to DLQ, doesn’t crash the consumer	In-process component tests
Ordering	Out-of-order messages produce documented outcomes	In-process component tests
Backpressure	Consumer slows when downstream is slow	Resilience component tests
Broker contract	Topic, schema, headers	Contract tests
Broker client	Real protocol behavior, offset commits, consumer group rebalancing	Adapter integration tests against a real broker container

Positive test cases

Common cases to consider, not an exhaustive list. Drop items that don’t apply and add ones the pattern doesn’t mention but your component needs.

Event Producer

Mon, 01 Jan 0001 00:00:00 +0000

The producer side, often paired with the Event consumer pattern in the same service. After a state change, the service publishes a message that downstream consumers depend on.

The hard problems differ from the consumer side: atomicity with persistence (did the DB row commit and the message publish?), exactly-once semantics that require an outbox or two-phase commit, and downstream consumer dependence on schema, routing key, and headers.

What needs covered

Layer	Concern	Test type
Outbox / transactional emit	DB write and message emit happen as a unit	Component tests with real DB + broker double
Produced message contract	Schema, headers, routing	Provider-side contract tests
Routing	Right topic and key per event type	Component tests
Retry on broker unavailable	Outbox drains once broker recovers	Component tests with fault-injecting broker client double
Trace propagation	Trace context in headers matches the inbound request	Component tests

Positive test cases

Common cases to consider, not an exhaustive list. Drop items that don’t apply and add ones the pattern doesn’t mention but your component needs.

CLI Tool or Library

Mon, 01 Jan 0001 00:00:00 +0000

A binary (CLI) or package (library) consumed by other developers. The “public interface” is the CLI invocation surface (argv, stdin, stdout, stderr, exit code) or the library’s exported API.

The pattern is different because the consumer is a developer or another program, not a user clicking a button. Cross-platform behavior, semantic versioning, and backward compatibility matter more than they do for a service.

What needs covered

Layer	Concern	Test type
Pure logic	Functions, classes, parsers	Solitary unit tests
CLI invocation	Argument parsing, exit codes, output streams	Component tests through the CLI entrypoint
Cross-platform	Path separators, line endings, signal handling	Cross-OS test matrix running the suite on every supported OS in CI
Public API surface	Library’s exported types and functions	API surface tests (snapshot of the public API; diff fails the build)
Documented examples	The README examples actually work	Doctests / executable docs

Positive test cases

Common cases to consider, not an exhaustive list. Drop items that don’t apply and add ones the pattern doesn’t mention but your component needs.

Stateful Service

Mon, 01 Jan 0001 00:00:00 +0000

A service that maintains long-lived in-memory state: caches, in-memory aggregates, leader-elected coordinators, websocket gateways, real-time engines, sticky-session servers.

The hard problems are concurrency, recovery, and unbounded growth. Stateful services fail in ways stateless services do not.

What needs covered

Layer	Concern	Test type
State machine logic	Pure transitions	Solitary unit tests
Persistence and checkpointing	State survives restart or rebuilds correctly	Component tests with real persistence
Recovery from crash	Restart converges to a consistent state	Component tests that simulate crash mid-write
Leader election	Only one leader; transitions are observable; split-brain is impossible	Cluster tests with real consensus library
Replication	Followers stay in sync; backpressure is documented	Cluster tests
Memory bounds	State doesn’t grow unbounded; eviction policy holds	Long-running soak tests
Connection lifecycle	Sessions clean up on disconnect; reconnect is documented	Component tests

Positive test cases

Common cases to consider, not an exhaustive list. Drop items that don’t apply and add ones the pattern doesn’t mention but your component needs.