From ork
Provides patterns for integration and contract testing: API endpoints, React components, database layers, Pact verification, property-based (Hypothesis), Zod schemas. Use for API boundaries, contracts, cross-service validation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ork:testing-integrationThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Focused patterns for testing API boundaries, cross-service contracts, component integration, database layers, property-based verification, and schema validation.
checklists/contract-testing-checklist.mdchecklists/property-testing-checklist.mdexamples/orchestkit-test-strategy.mdreferences/consumer-tests.mdreferences/pact-broker.mdreferences/provider-verification.mdreferences/strategies-guide.mdrules/_sections.mdrules/emulate-stateful-testing.mdrules/integration-api.mdrules/integration-component.mdrules/integration-database.mdrules/validation-zod-schema.mdrules/verification-contract.mdrules/verification-stateful.mdrules/verification-techniques.mdscripts/create-integration-test.mdscripts/test-plan-template.mdtest-cases.jsonFocused patterns for testing API boundaries, cross-service contracts, component integration, database layers, property-based verification, and schema validation.
| Area | Rule / Reference | Impact |
|---|---|---|
| Stateful API testing (emulate) | rules/emulate-stateful-testing.md | HIGH |
| API endpoint tests | rules/integration-api.md | HIGH |
| React component integration | rules/integration-component.md | HIGH |
| Database layer testing | rules/integration-database.md | HIGH |
| Zod schema validation | rules/validation-zod-schema.md | HIGH |
| Pact contract testing | rules/verification-contract.md | MEDIUM |
| Stateful testing (Hypothesis) | rules/verification-stateful.md | MEDIUM |
| Evidence & property-based | rules/verification-techniques.md | MEDIUM |
| Topic | File |
|---|---|
| Consumer-side Pact tests | references/consumer-tests.md |
| Pact Broker CI/CD | references/pact-broker.md |
| Provider verification setup | references/provider-verification.md |
| Hypothesis strategies guide | references/strategies-guide.md |
| Checklist | File |
|---|---|
| Contract testing readiness | checklists/contract-testing-checklist.md |
| Property-based testing | checklists/property-testing-checklist.md |
| Script | File |
|---|---|
| Create integration test | scripts/create-integration-test.md |
| Test plan template | scripts/test-plan-template.md |
| Example | File |
|---|---|
| Full testing strategy | examples/orchestkit-test-strategy.md |
For GitHub, Vercel, and Google API integration tests, emulate is the first choice. It provides full state machines that model real API behavior — not static mocks.
| Tool | Best For |
|---|---|
| emulate | Stateful API tests (GitHub/Vercel/Google) — FIRST CHOICE |
| Pact | Cross-team contract verification |
| MSW | Frontend HTTP mocking (simple request/response) |
| Nock | Node.js unit-level HTTP interception |
See rules/emulate-stateful-testing.md for the full decision matrix, seed-start-test-assert pattern, and incorrect/correct examples.
import request from 'supertest';
import { app } from '../app';
describe('POST /api/users', () => {
test('creates user and returns 201', async () => {
const response = await request(app)
.post('/api/users')
.send({ email: '[email protected]', name: 'Test' });
expect(response.status).toBe(201);
expect(response.body.id).toBeDefined();
expect(response.body.email).toBe('[email protected]');
});
test('returns 400 for invalid email', async () => {
const response = await request(app)
.post('/api/users')
.send({ email: 'invalid', name: 'Test' });
expect(response.status).toBe(400);
expect(response.body.error).toContain('email');
});
});
import pytest
from httpx import AsyncClient
from app.main import app
@pytest.fixture
async def client():
async with AsyncClient(app=app, base_url="http://test") as ac:
yield ac
@pytest.mark.asyncio
async def test_create_user(client: AsyncClient):
response = await client.post(
"/api/users",
json={"email": "[email protected]", "name": "Test"}
)
assert response.status_code == 201
assert response.json()["email"] == "[email protected]"
| Area | Target |
|---|---|
| API endpoints | 70%+ |
| Service layer | 80%+ |
| Component interactions | 70%+ |
| Contract tests | All consumer-used endpoints |
| Property tests | All encode/decode, idempotent functions |
Like(), EachLike(), Term() instead of exact values.safeParse() at every API boundaryork:testing-unit — Unit testing patterns, fixtures, mockingork:testing-e2e — End-to-end Playwright testsork:emulate-seed — Seed configuration authoring for emulate providersork:database-patterns — Database schema and migration patternsork:api-design — API design patterns for endpoint testingnpx claudepluginhub yonatangross/orchestkit --plugin orkTests API endpoints, validates consumer-driven contracts between microservices, and verifies database interactions against real infrastructure.
Guides writing integration tests that verify component interactions (database, API, message bus) with real dependencies. Covers contract testing as a lighter alternative for service boundaries.
Provides test pyramid guidance, coverage targets, and patterns for unit, integration, E2E, performance, and security tests in PACT Test phase. Useful for designing test suites and prioritizing coverage.