integration-testing

Write integration tests against real databases, HTTP endpoints, and message brokers using Testcontainers and Pact.

1|Updated Mar 18, 2026
One-click install
npx skills add https://github.com/MARUCIE/openclaw-foundry --skill integration-testing-marucie
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: integration-testing
Source: https://github.com/MARUCIE/openclaw-foundry/tree/main/web/public/packs/spellbook-test-engineer/skills/integration-testing
Command: npx skills add https://github.com/MARUCIE/openclaw-foundry --skill integration-testing-marucie

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Unit tests with mocked dependencies miss bugs in real database queries, HTTP middleware wiring, serialization, and service-to-service contracts. This Skill provides patterns for testing components against real infrastructure so integration bugs surface before production. ## Core Features & Use Cases - Testcontainers Database Testing: Spin up real Postgres, MySQL, Redis, or Kafka containers per test suite in Python, TypeScript, or Go, with transaction-rollback isolation and schema migrations run before the suite. - HTTP API and Contract Testing: Exercise full request/response cycles with TestClient, supertest, or httptest, and verify cross-service agreements with consumer-driven Pact contracts. - Message Queue and Test Data Management: Test event producers and consumers, build fixture factories, and apply cleanup strategies like transaction rollback and per-worker schema isolation. - Use Case: A team adding a new orders endpoint uses Testcontainers to run tests against a real Postgres instance, writes supertest lifecycle tests for the API, and publishes a Pact contract so the consuming billing service can verify compatibility independently. ## Quick Start Ask the AI to set up integration tests for your service using Testcontainers with a real Postgres database and transaction rollback per test.

Frequently Asked Questions about integration-testing

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

FAQPage Schema
How do I write integration tests with Testcontainers?▼

Testcontainers starts a real Docker container such as Postgres or Kafka per test session, giving every developer and CI run an identical isolated database. Run schema migrations against the container before the suite, then wrap each test in a transaction that rolls back for cleanup.

What is the difference between unit tests and integration tests?▼

Unit tests mock I/O and run in milliseconds, while integration tests use real databases, routers, and brokers to catch schema, serialization, and middleware bugs. A common starting split is 70% unit, 20% integration, and 10% end-to-end tests.

When should I use Pact contract testing?▼

Use Pact when microservices owned by different teams deploy independently and need to verify API agreements without running both services. Skip it for monolith internal calls, same-team service pairs, or third-party APIs where recorded fixtures work better.

Why do my integration tests fail in CI but pass locally?▼

Common causes are missing Docker socket access on the CI runner, shared test databases corrupted by parallel workers, and hardcoded test emails causing unique constraint violations. Verify Docker availability, isolate workers with separate schemas, and use factories with sequences or UUIDs.

How do I clean up test data between integration tests?▼

Transaction rollback is the fastest and most reliable cleanup strategy for most suites, requiring a single connection per test. Alternatives include truncating tables after the suite, per-worker schemas for parallel runs, or dropping worker-specific databases.

Can Testcontainers run in CI without local Docker?▼

Yes, Testcontainers Cloud offloads container startup to a remote daemon for sandboxed or rootless CI environments. You can also cache container images and verify Docker socket access early to avoid blocked pipelines.