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.
npx claudepluginhub yonatangross/orchestkit --plugin orkThis skill is limited to using the following tools:
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.jsonConducts service boundary testing, API contract verification, and consumer-driven contract validation for microservices without full end-to-end infrastructure.
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.
Provides testing pyramid, unit patterns (AAA, isolation, parameterized, edge cases), and React Testing Library for component tests. Use when writing tests or setting up testing infrastructure.
Share bugs, ideas, or general feedback.
Focused 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: 'test@example.com', name: 'Test' });
expect(response.status).toBe(201);
expect(response.body.id).toBeDefined();
expect(response.body.email).toBe('test@example.com');
});
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": "test@example.com", "name": "Test"}
)
assert response.status_code == 201
assert response.json()["email"] == "test@example.com"
| 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 testing