skills.rest
Nandansai08
Nandansai08COMMUNITY
Explore all skills by this author →
WebsiteGitHub

integration-test-strategy

Plans integration tests against real databases, queues, and services using testcontainers and contract tests.

1|Updated Jul 3, 2026
Search Tags:#integration testing#pytest#database testing#contract testing#testcontainers#pact#test isolation
One-click install
npx skills add https://github.com/Nandansai08/skillz --skill integration-test-strategy-nandansai08
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: integration-test-strategy
Source: https://github.com/Nandansai08/skillz/tree/main/skills/testing-qa/integration-test-strategy
Command: npx skills add https://github.com/Nandansai08/skillz --skill integration-test-strategy-nandansai08

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams with all-mocked unit test suites keep hitting production failures at the seams — SQL constraint violations, serialization mismatches, framework wiring bugs — because mocks only encode beliefs about dependencies, never verify them. This Skill provides a workflow for deciding what to test with real components wired together versus unit tests. ## Core Features & Use Cases - Seam Selection: Identifies where integration tests belong (real SQL execution, ORM mappings, queue serialization, HTTP contracts) and enforces one real integration per test. - Real Engines via Testcontainers: Replaces H2/SQLite/fakeredis lookalikes with pinned-version containers (Postgres, Redis, Kafka, LocalStack) so tests match production behavior. - Structural Isolation & Migration Testing: Covers transaction-rollback or schema-per-worker isolation and building test schemas via real migrations instead of create_all(). - Contract Testing: Uses Pact or recorded fixtures for cross-service boundaries instead of booting other teams' services in CI. - Use Case: A payments service with 400 mocked unit tests suffers repeated SQL constraint and Kafka serialization incidents; applying this Skill adds 25 testcontainer-backed repository tests, 6 serialization round-trip tests, and Pact contracts, eliminating seam incidents the next quarter. ## Quick Start Ask the AI to design an integration test strategy for your service, specifying which dependencies (database, queue, downstream APIs) should be tested with real components versus stubs.

Frequently Asked Questions about integration-test-strategy

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

FAQPage Schema
How do I decide between unit tests and integration tests?▼

Put integration tests where beliefs about dependencies are least trustworthy: real SQL execution, ORM mappings, queue serialization round-trips, and framework wiring. Keep units fast and logic-focused; test one real integration per test rather than wiring multiple components together.

Should I use Testcontainers or an in-memory database like H2 for testing?▼

Use Testcontainers with the real engine pinned to your production version, such as postgres:16.3. In-memory substitutes like H2, SQLite, or fakeredis pass tests that fail in production on dialect differences, locking, and expiry semantics.

How do I isolate integration tests so they can run in parallel?▼

Make isolation structural: per-test transaction rollback is fastest, schema-per-worker supports parallel runs, and truncate-between-tests is the slowest fallback. Never share mutable rows across tests, since that creates order-dependent flaky suites.

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

Contract tests verify cross-service boundaries by having consumers write expectations (via Pact or recorded fixtures) that providers verify in their own CI. This avoids booting another team's service in your pipeline, which couples deploys and doubles the flake surface.

Why should test schemas be built with migrations instead of create_all?▼

Building test schemas with real migrations keeps migration files exercised; create_all() from models lets migrations diverge from the models and rot untested until a production deploy fails. Run the actual migration files in test setup.

When should I not use integration tests?▼

Avoid integration tests for browser-driven full-system flows, which belong in e2e testing, and for pure logic branches that should be fast unit tests. Driving every if-statement through the database creates slow, bloated suites that miss CI time budgets.

Related Skills

Explore More Software Engineering Skills→
open-haxopen-hax
6

testing-general

Define testing strategies and coverage goals for software projects.

Official
Intermediate
Awais68Awais68

api-testing

Test FastAPI backends and React/Next.js frontends with pytest, TestClient, and Playwright.

Community
Advanced
AGIBuildAGIBuild
10

dotnet-testing-strategy

Select .NET testing strategies using a decision framework for unit, integration, and E2E tests.

Community
Intermediate
dprice-devdprice-dev

contract-testing

Run Pact consumer tests and provider verification for microservices.

Community
Advanced