just-vibeTesting · apply by default
/test-fixtures
Create representative, maintainable test data
Use for controlled test data and factories; data-profile inspects real datasets.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select test-fixtures from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv test-fixtures, /just-vibe test-fixtures and /jv:test-fixtures in Claude. See shortcut setup and context examples.
/just-vibe:test-fixtures Build deterministic organization fixtures safe for concurrent test runs./just-vibe:test-fixtures Build fixtures whose teardown still runs when setup fails halfway through creating an organization./just-vibe:test-fixtures Design fixtures without copying production personal records.What the agent does
- Derive minimal realistic entities with valid defaults and deliberate invalid variants.
- Isolate identifiers, timestamps and clocks, and make teardown safe after a partial setup failure.
- Verify cleanup, repeatability and concurrent use.
Inputs
- behaviors, schema, edge cases, existing factories, and privacy constraints.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Representative deterministic test data and lifecycle helpers.
- 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; behaviors, schema, edge cases, existing factories, and privacy constraints.
- 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
- Fixtures or factories with their contract, edge variants, usage, cleanup behavior and concurrency checks.
How the work is checked
- Two concurrent tests do not collide on shared identifiers; boundary cases remain explicit rather than accidental random data.
When to stop or clarify
- Never copy raw production personal data for convenience. Avoid large opaque snapshots that hide which conditions matter.
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
- Identify representative valid defaults, intentional invalid variants, ownership and cleanup requirements.
- Method
- Construct minimal realistic data with explicit timestamps/IDs and independent expected values; avoid production data copies.
- Pitfall
- A globally shared mutable fixture can make tests order-dependent; overly permissive mocks erase real constraints.
- Check
- Run fixtures concurrently or in different orders and verify cleanup after failure plus the expected invalid-case rejection.
Situational decisions
When random generation makes failures hard to reproduce: Use a recorded seed and expose the important boundary explicitly.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.