dev-e2e-testing

Write end-to-end tests against real databases, brokers, blockchains, and sockets with network-fault injection.

2|Updated May 16, 2026
One-click install
npx skills add https://github.com/avbel/ai-skills --skill dev-e2e-testing-avbel
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dev-e2e-testing
Source: https://github.com/avbel/ai-skills/tree/main/skills/dev-e2e-testing
Command: npx skills add https://github.com/avbel/ai-skills --skill dev-e2e-testing-avbel

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Unit and in-memory integration tests cannot catch failures that only appear over real sockets, real wire protocols, and real infrastructure — such as timeout misconfiguration, partial writes, packaging bugs in published SDKs, and non-idempotent retries. This Skill defines a production-parity e2e testing tier that runs every dependency as the real engine locally and injects network faults to verify behavior under failure. ## Core Features & Use Cases - Production-parity stack: Real PostgreSQL (dropped and recreated per run), disposable Valkey, real brokers (Redpanda, NATS, RabbitMQ), and local blockchain networks (Sui localnet, Anvil) instead of in-memory shims or client mocks. - Mandatory network-fault injection: Toxiproxy-based scenarios covering latency, black holes, connection resets, bandwidth throttling, flapping, and recovery, with assertions on deadlines, idempotency, and clean recovery. - SDK verification: Generates standalone smoke programs that consume packed SDK tarballs as real users would, catching broken exports and packaging bugs that in-process tests miss. - Use Case: Before a release, run test:e2e to spin up Postgres, Valkey, and Redpanda via Docker Compose, execute critical user journeys over real sockets, then verify the service honors its configured timeouts and retries idempotently when Toxiproxy black-holes the database connection. ## Quick Start Ask the agent to set up an e2e test tier with real Postgres and Valkey containers, a Toxiproxy fault-injection harness, and a separate test:e2e command that runs outside the per-commit fast path.

Frequently Asked Questions about dev-e2e-testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write end-to-end tests against a real database?▼

Use Testcontainers or a compose-managed instance, drop and recreate the database before each run, then apply real production migrations. Pin the image tag to the production major version, such as postgres:17.4, and never truncate-and-hope between runs.

How do I test network failures and timeouts in integration tests?▼

Route each app-to-dependency hop through Toxiproxy and apply toxics like latency, timeout, reset_peer, and bandwidth limits. Assert behavior under failure: configured deadlines honored, idempotent retries, no partial writes, and clean recovery after toxics are removed.

Should e2e tests use in-memory databases like pg-mem?▼

No — at the e2e tier, in-memory shims like pg-mem and mongodb-memory-server are anti-patterns because they cannot reproduce real wire protocols and failure modes. Use the real server in a disposable container; in-memory fakes belong to the faster everyday integration tier.

How do I test blockchain transactions locally without a testnet?▼

Run a local network: sui start --with-faucet --force-regenesis for Sui, or anvil --port 8545 for Ethereum-like chains with deterministic funded accounts. Never point e2e tests at public testnets, which are slow, rate-limited, and shared.

When should e2e tests run in CI?▼

Run them on a nightly schedule, manual dispatch, and as a pre-release gate — never in the per-commit fast path. Container startup is too expensive for every commit; the everyday integration suite covers the fast feedback loop.

What if Docker is not available in the CI environment?▼

Fall back to native binaries for everything that has one, such as valkey-server, nats-server, and anvil, and skip-with-a-visible-reason any test whose dependency truly cannot run. The suite must still execute rather than silently passing.