Applied Testing Strategies on MinimumCD Practice Guide

Pre-Ship Checklist

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

Use this as a set of prompts for a quick self-audit, not a list of gates that must all pass. Items that don’t apply to a component can be ignored; items the list doesn’t mention but your component clearly needs should be added. Walk back to the pattern or cross-cutting concern that needs attention for any item that prompts a “we should fix that.”

The bulk of the suite is sociable unit tests that exercise how behaviors collaborate to deliver a domain operation. Solitary unit tests are reserved for genuinely complex pure logic.
Tests are organized around domain operations, not around classes or methods. Test names read as something a stakeholder would recognize.
Every public-interface contract (inbound and outbound) has a contract test running in the pipeline.
Classes are tested through their public methods only. No reflection, no test-only visibility relaxations, no asserting on private state.
Every consumed external dependency is wrapped in a gateway the team owns; doubles are of the gateway, not of the third-party library.
Every boundary adapter has an adapter integration test against the real dependency or a high-fidelity stand-in (testcontainer, WireMock with provider fixtures).
The bulk of testing runs in-band in the pipeline and gates the build; out-of-band checks against real systems run on a schedule and trigger review on failure, never a build break.
Every test double has a corresponding non-deterministic check that exercises the real dependency on a schedule or post-deploy.
Every documented failure mode has a negative test.
Every error response has a test that verifies the error envelope, status code, and any side effects (or absence thereof).
Time, randomness, and the network are injected, not called directly. No sleep in tests. Use bounded polling or a fake clock.
All deterministic tests run pre-commit and in CI Stage 1, and fail the build on failure.
All post-deploy integration checks run out of pipeline and trigger review on failure, never blocking a commit.
Pipeline gates map to defect sources from the Systemic Defect Fixes catalog. If a defect category has no automated check, that’s a known risk.
Authn and authz are tested across every protected endpoint, not as one-offs per feature.
Database migrations are tested forward, backward (where supported), and on representative data volume against the production engine.
Fixtures are generated from the schema or built through Object Mother / builder helpers, not inline literals.
Failure-path tests assert on observability (metric incremented, structured log emitted with correlation ID), not just the response.
Per-endpoint perf budgets exist for hot paths; load tests gate production promotion; soak tests run out of pipeline.
Flaky tests are quarantined with a dated owner and time-boxed remediation. No permanent quarantine list.
The deterministic suite respects the pattern’s time budget (under 5 to 8 minutes per component, under 10 minutes total).

Cross-Cutting Concerns

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

The patterns describe testing organized by component shape. The concerns below cut across all patterns and deserve dedicated coverage in any non-trivial system.

Authn and authz testing

Authentication and authorization deserve dedicated, exhaustive coverage. They are a major source of high-impact incidents and the failure modes are predictable:

Tenant isolation: tenant A’s queries never return tenant B’s data. Test every read path. Multi-tenant SaaS bugs are almost always missing isolation tests.
Scope or role escalation: a token with read:orders cannot perform write:orders. Test the matrix of scope and endpoint.
Expired tokens: rejected even if cached locally. Clock-skew tolerance is a property of the verifier, not a license to skip the test.
Forged tokens: signature validation actually validates. The classic JWT alg: none bug still ships periodically.
Missing auth: every protected endpoint returns 401, never 500 (information leak) and never 200 (catastrophic).
Service-to-service auth: machine identities respected, mTLS validated, token-swapping attacks detected.

The pattern: a parameterized test that takes (endpoint, method, expected-status-when-no-token, expected-status-when-wrong-scope) and runs across every endpoint in the OpenAPI or schema definition. New endpoints are covered automatically.