vetta-testing

Designs, writes, and reviews behavior-focused tests for OpenVetta feature changes and bug fixes.

154|27|Updated Aug 3, 2026
One-click install
npx skills add https://github.com/openvetta/open-vetta --skill vetta-testing-openvetta
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: vetta-testing
Source: https://github.com/openvetta/open-vetta/tree/main/.agents/skills/vetta-testing
Command: npx skills add https://github.com/openvetta/open-vetta --skill vetta-testing-openvetta

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It ensures that code changes in the OpenVetta repository are covered by tests that actually fail when real regressions occur, instead of tests that only chase line coverage, internal call counts, or brittle snapshots. ## Core Features & Use Cases - Behavior-first test design: Defines user-visible behaviors, invariants, and common usage flows as Given/When/Then scenarios before writing any test code. - Task-matched test selection: Chooses the right mix of unit, component, contract, integration, and E2E tests for bug fixes, new features, refactors, public contract changes, and UI interactions. - Test quality review: Provides a checklist for auditing tests on regression detection, mock boundaries, async determinism, and diagnostic failure messages. - Use Case: After fixing a bug where a rejected tool permission still executed the action, use this Skill to write a regression test proving the operation is blocked and the user sees a cancelled state, then run it through the repository's unified test commands. ## Quick Start Ask the agent to design and write regression tests for your OpenVetta change following the vetta-testing guidelines, then run them with the repository's unified test commands.

Frequently Asked Questions about vetta-testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write regression tests for a bug fix in OpenVetta?▼

First establish a minimal reproduction or baseline that fails on the old implementation, then write a regression test covering the affected common user flow. After the fix, run the targeted test plus the impacted user flow tests through the repository's unified test commands.

What test level should I use for UI interaction changes?▼

Use component tests that cover real rendering, event wiring, user input, submission, focus, accessibility semantics, and loading or error recovery. Pure function tests cannot replace component tests, and E2E is reserved for boundaries lower layers cannot prove.

When should mocks be used in OpenVetta tests?▼

Mocks belong only at true external boundaries such as providers, network, operating system, external processes, or uncontrollable time. Internal collaborators should use real implementations, in-memory stores, or behavior-explicit fakes instead of verifying internal call counts.

Can I run vitest directly instead of the repository test commands?▼

No. The repository requires its unified entry points such as bun scripts/quality/run-vitest.mjs, bun run test:pkg, test:changed, check:quick, and check. Bare bun test, bunx vitest, npx vitest, or direct vitest invocations are not allowed.

When is it acceptable to skip adding new tests?▼

Pure documentation changes, logic-free copy edits, type forwarding, or mechanical changes already covered by existing contracts may skip new tests. You must still run appropriate verification and explain the reasoning in the delivery notes.