/test-unit

Make it your own.

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

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

What the agent does

1. Select a public behavior and its observable inputs and outputs, with an independent expected result.
2. Choose minimal valid fixtures and write focused tests that cover a meaningful invalid or boundary input without asserting private implementation steps.
3. Run the relevant suite.

Inputs

• unit/behavior, edge cases, and existing test framework.

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

Scope

Reads

Isolated contracts and invariants with minimal justified mocks.

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; unit/behavior, edge cases, and existing test framework.

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

• Unit tests mapped to behaviors with fixture rationale, independent assertions and observed results.

How the work is checked

• A behavioral defect makes a test fail; internal reorganization preserving the contract does not require rewriting every assertion.

When to stop or clarify

• Do not mock the unit's entire implementation or add tests solely for trivial coverage. Missing runners are reported without fake results.

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 the public behavior, pure boundary, dependencies and independently derivable expectations.

Method

Choose small examples around equivalence classes and exact boundaries; control clock/randomness rather than sleeping.

Pitfall

Asserting internal helper calls or computing expected results with the implementation repeats its mistakes.

Check

Demonstrate that a plausible wrong result fails an assertion while valid empty/zero/boundary cases pass.

Situational decisions

When heavy mocking hides the behavior under test: Move the test to the appropriate integration layer or replace only the true external boundary.

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