What To Test
Decide what to test in the ai-hero CLI and how to structure tests without chasing coverage for its own sake.
Install
npx skills add https://github.com/mattpocock/ai-hero-cli --skill what-to-testWhat is this skill?
- Tests user-facing behavior—including every CLI command, including internal ones Matt uses daily
- Four-step pattern: export runX(), mock GitService/PromptService, hit real user error paths, v8 ignore presentation wirin
- Explicit do-not-test list: real git/shell/fs boundaries, mocked service layers, DI entry points, boilerplate branches
- Coverage is a guide to find untested user-facing behavior—not a goal to inflate numbers
Adoption & trust: 8 installs on skills.sh; 61 GitHub stars; 3/3 security scanners passed (skills.sh audits).
Recommended Skills
Agent Browservercel-labs/open-agents
Tddmattpocock/skills
Use My Browserxixu-me/skills
Test Driven Developmentobra/superpowers
Verification Before Completionobra/superpowers
Webapp Testinganthropics/skills
Journey fit
Primary fit
Canonical shelf is Ship because the skill governs test strategy and regression protection right before and during release-quality work. Testing subphase fits user-facing behavior tests, mocked services, and v8 ignore guidance for a Node CLI.
Common Questions / FAQ
Is What To Test safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.
SKILL.md
READMESKILL.md - What To Test
# What to Test ## Philosophy Test user-facing behavior. If a user would notice it's broken, it needs a test. All CLI commands must be tested - including commands marked "internal". Internal commands are still user-facing (Matt uses them daily). ## What Makes a Good Test - Tests behavior users depend on - Validates real workflows, not implementation details - Catches regressions before users do Do NOT write tests just to increase coverage numbers. Use coverage as a guide to find untested user-facing behavior. ## What NOT to Test Use `/* v8 ignore start */` for: - Integration boundaries (actual git calls, shell execution, filesystem) - Service layers that get mocked in tests - Entry points and DI wiring - Boilerplate, unreachable error branches ## Testing Pattern 1. Export a `runX()` function from command files for testability 2. Mock external services (GitService, PromptService) 3. Test error paths users will actually hit 4. Use v8 ignore for CLI formatting/presentation code