/test-integration

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select test-integration from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv test-integration, /just-vibe test-integration and /jv:test-integration in Claude. See shortcut setup and context examples.

What the agent does

1. Choose an authorized isolated dependency instance or existing fixture environment, and control data identity with setup and cleanup.
2. Exercise the actual interfaces, verifying persistence, serialization and failure cleanup across the boundary.
3. Record what remains mocked.

Inputs

• interacting components, actual dependency types, contracts, and isolated environment.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Real boundaries such as database transactions, serialization, queues, or service adapters.

Writes

Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.

Mode

Apply; interacting components, actual dependency types, contracts, and isolated environment.

Prerequisites

Defined behavior, existing test conventions/runners, isolated fixtures, and relevant dependencies. Requested bounded verification may use owned isolated fixtures without authorizing product edits or live-system tests. Never test destructive behavior against production by default; distinguish mocked behavior from real integration evidence.

Expected output

• Integration tests with reproducible environment instructions, dependency/version, fixture lifecycle and normal/error/rollback observations.

How the work is checked

• A schema/serialization mismatch is caught; a failed transaction leaves no partial committed effect.

When to stop or clarify

• No shared/production database use by assumption. Inaccessible dependencies produce blocked checks, not replacement mocks labeled as real integration.

Handling missing context

Infer

Read behavior contracts, existing runners and test conventions; distinguish fixture setup failure from a behavioral failure.

Assume

Use the smallest existing local runner and isolated synthetic fixtures that distinguish the requested behavior. When the method needs a library, runner, container runtime or load tool the project lacks, name the exact package or tool, the files it changes and any download, and add it only when the request authorizes new dev dependencies or tools; label a hand-written generator without shrinking, or a fake in place of a real dependency, as such.

Ask

Ask about an unresolved contract that changes the expected result, or the target/load limits before external testing; do not ask the user to choose a runner already configured.

Technical guidance

Evidence

Locate the real serialization, database, process or provider boundary and isolated test target.

Method

Exercise actual boundary semantics with deterministic fixtures and cleanup after partial setup.

Pitfall

An in-memory substitute may not match transaction isolation, collation or permission behavior of the deployed engine.

Check

Test one success and a boundary failure on the intended technology/version and report which dependencies remain simulated.

Situational decisions

When only a fake dependency is available: Label contract assumptions and avoid claiming the real database/provider was exercised.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring