E2E Testing — Production-Parity Tier

Everything real except other people's clouds. Every dependency the code talks to in production runs locally as the real engine — real sockets, real wire protocols, real failure modes. Only external vendor APIs (things you cannot run locally) are mocked, and only at the HTTP boundary. Part of the dev-* development-cycle skill set (see dev-cycle).

This is a separate, slower tier — not the regular suite. These tests do NOT run on every test invocation, pre-commit, or PR-fast-path. They get their own command (test:e2e / cargo test --features e2e / a -tags e2e build tag) and run on demand and in nightly/pre-release CI. The everyday integration suite is dev-testing's job; never make developers pay the container-startup tax for a parser change.

When to Use This Tier (and When Not)

Use for:

• Release-gate suites: the critical user journeys through the fully assembled system
• Resilience verification: retries, timeouts, idempotency, recovery under network faults
• SDK verification: does generated/published client code actually work against a live stack
• Blockchain flows: contract deploy + transaction paths that unit tests cannot fake

Do NOT use for: pure logic, single-component behavior, or anything dev-testing's in-memory tier already covers. If a bug is reproducible with pg-mem and msw, it does not need this tier. And when the user wants a one-off, human-in-the-loop verification session rather than a durable suite ("run it and let's check it works"), that's manual-testing-node-js — its confirmed plan items are good seeds for this tier's journey tests later.

Stack Rules

Create unique run-owned databases, containers, networks, key prefixes, and chain data directories. Verify ownership before any drop/reset/flush/regenesis or volume removal; a local address or test-like name is not proof. Never clean up shared development or production resources. Use isolated instances for whole-server fault injection and flushes.