test-environments

Design production-parity test environments with Dockerized infrastructure and HTTP-boundary stubs.

2|Updated Apr 18, 2021
One-click install
npx skills add https://github.com/rabbicse/go-projects --skill test-environments-rabbicse
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-environments
Source: https://github.com/rabbicse/go-projects/tree/main/projects/movie-ticket-booking/.claude/skills/test-environments
Command: npx skills add https://github.com/rabbicse/go-projects --skill test-environments-rabbicse

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill prevents flaky tests and staging drift by helping you design reliable environment tiers that mirror production where bugs hide, isolate per-PR preview environments, and keep local, CI, staging, and production behavior reproducible.

Core Features & Use Cases

  • Environment Tier Design: Map local dev, CI, preview, staging, and production into a clear lifecycle with the right data, lifecycle, and access model for each tier.
  • Dockerized Test Infrastructure: Set up multi-stage Dockerfiles and Docker Compose test stacks with health checks, one-shot seed containers, and deterministic startup ordering.
  • External Dependency Stubbing: Stub third-party APIs at the HTTP boundary with loud failures for unhandled requests so non-production runs stay fast and deterministic.
  • Practical Use Case: Use this Skill when staging behaves differently from production, when CI flakes because of live integrations, or when you need a per-PR environment that reviewers can safely exercise without shared-state collisions.

Quick Start

Ask the skill to design a production-parity test environment for your repository, including the compose stack, seed lifecycle, preview environment flow, and external dependency stubbing strategy.

Frequently Asked Questions about test-environments

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

FAQPage Schema
How do I stop flaky tests caused by staging drift and live integrations?

To stop flaky tests from staging drift, design production-parity test environments that mirror production infrastructure and stub external HTTP dependencies with loud failures for unhandled requests.

What is the best way to isolate preview environments per pull request?

The best way to isolate preview environments per pull request is to design per-PR containerized test stacks using Docker Compose with deterministic startup ordering and idempotent seed data.

How do I configure Docker Compose test stacks with deterministic startup?

Configure Docker Compose test stacks for deterministic startup by using health-checked multi-stage containers, one-shot seed containers, and explicit dependency ordering across databases, queues, and auth services.

How does HTTP boundary stubbing work for external dependencies in CI?

HTTP boundary stubbing for external dependencies in CI works by intercepting third-party API calls and returning loud failures for unhandled requests, keeping non-production runs fast and deterministic.

When do I need idempotent seed data lifecycles in test environments?

You need idempotent seed data lifecycles in test environments when mapping local dev, CI, preview, and staging tiers to ensure data remains reproducible and consistent without shared-state collisions.

Can I use this approach to map environment tiers from local dev to production?

Yes, you can use this approach to map environment tiers from local dev to production by applying documented parity checks across databases, queues, auth, and external services for each lifecycle stage.