ha-test-strategy

Selects appropriate test strategies and layers for code changes based on risk.

1.6k|149|Updated Mar 13, 2026
One-click install
npx skills add https://github.com/shiwenwen/hope-agent --skill ha-test-strategy
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ha-test-strategy
Source: https://github.com/shiwenwen/hope-agent/tree/main/skills/ha-test-strategy
Command: npx skills add https://github.com/shiwenwen/hope-agent --skill ha-test-strategy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Deciding which tests to write for a feature, bug fix, or refactor is often inconsistent and subjective. This Skill provides a structured decision framework that matches the right testing approach to the risk and nature of each code change.

Core Features & Use Cases

  • Strategy Selection: Chooses among test-first, regression-first, characterization-first, implementation-first with coverage, or no new test based on the change type.
  • Layer Guidance: Directs tests to the lowest sufficient layer—unit, integration, E2E, or manual smoke—so effort matches the boundary being proven.
  • Quality and Execution Rules: Enforces behavior-focused assertions, deterministic fixtures, and an efficient narrow-to-broad test execution order.
  • Use Case: When fixing a bug in a legacy parser, the Skill guides you to reproduce the failure in a narrow regression test first, then verify the root-cause fix without freezing broken behavior.

Quick Start

Ask the agent to choose and add the right regression test for the bug you are fixing.

Frequently Asked Questions about ha-test-strategy

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

FAQPage Schema
How do I choose the right test strategy for a bug fix?▼

Use a regression-first approach: reproduce the original failure in the narrowest credible automated test, confirm it fails for the right reason, then verify it passes after the root-cause fix. This proves the fix addresses the actual bug.

When should I write tests before implementation?▼

Test-first works best when the new contract is clear, the test seam is stable, and observing the failure proves the test is meaningful. It is a valuable technique, not an unconditional law for every change.

Should I use unit tests or E2E tests for my change?▼

Use the lowest layer that proves the contract: unit tests for pure logic, integration for persistence or cross-module contracts, and E2E only for user-critical paths spanning the full stack. Add higher layers only for boundaries lower layers cannot cover.

How do I test legacy code during a refactor?▼

Use characterization-first testing: capture current intentional behavior before changing structure. Do not freeze a known bug as desired behavior—only preserve behavior that is genuinely correct.

When is it acceptable to skip writing new tests?▼

Skipping new tests is reasonable for pure docs, trivial metadata, generated outputs, or low-risk mechanical changes when existing checks already cover the risk. Explain the decision rather than adding a meaningless test.

What should I do when a test is flaky or environment-blocked?▼

Investigate the root cause of the flakiness or environment issue instead of rerunning until green. Repeatedly rerunning a flaky test until it passes does not constitute proof of correctness.