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.