본문으로 건너뛰기
cccskills
무료GitHub에 공개

coverage-strategist

Defines ROI-based coverage targets with critical path identification, layer-specific targets, and explicit "don't test this" guidelines. Use for "test coverage", "coverage strategy", "test priorities", or "coverage targets".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md9.1 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Coverage Strategist

Define pragmatic, ROI-focused test coverage strategies.

Coverage Philosophy

Goal: Maximum confidence with minimum tests

Principle: 100% coverage is not the goal. Test what matters.

Critical Path Identification

// Critical paths that MUST be tested
const criticalPaths = {
  authentication: {
    priority: "P0",
    coverage: "100%",
    paths: [
      "User login flow",
      "User registration",
      "Password reset",
      "Token refresh",
      "Session management",
    ],
    reasoning: "Security critical, impacts all users",
  },

  checkout: {
    priority: "P0",
    coverage: "100%",
    paths: [
      "Add to cart",
      "Update cart",
      "Apply coupon",
      "Process payment",
      "Order confirmation",
    ],
    reasoning: "Revenue critical, business essential",
  },

  dataIntegrity: {
    priority: "P0",
    coverage: "100%",
    paths: [
      "User data CRUD",
      "Order creation",
      "Inventory updates",
      "Database transactions",
    ],
    reasoning: "Data corruption would be catastrophic",
  },
};

// Important but not critical
const importantPaths = {
  userProfile: {
    priority: "P1",
    coverage: "80%",
    paths: ["Profile updates", "Avatar upload", "Preferences"],
    reasoning: "Important UX, but not business critical",
  },

  search: {
    priority: "P1",
    coverage: "70%",
    paths: ["Product search", "Filters", "Sorting"],
    reasoning: "Enhances experience, not essential",
  },
};

Layer-Specific Targets

# Coverage Targets by Layer

## Business Logic / Core Functions: 90-100%

**Why**: High ROI - complex logic, many edge cases
**What to test**:

- Calculations
- Validations
- State machines
- Algorithms
- Data transformations

## API Endpoints: 80-90%

**Why**: Critical integration points
**What to test**:

- Happy paths
- Error cases
- Validation
- Authentication
- Authorization

## Database Layer: 70-80%

**Why**: Data integrity matters
**What to test**:

- CRUD operations
- Transactions
- Constraints
- Migrations

## UI Components: 50-70%

**Why**: Lower ROI - visual changes, less critical
**What to test**:

- User interactions
- State changes
- Error states
- Critical flows only

## Utils/Helpers: 80-90%

**Why**: Reused everywhere, high impact
**What to test**:

- All public functions
- Edge cases
- Error handling

"Don't Test This" List

// Explicit list of what NOT to test

const dontTestThese = {
  externalLibraries: {
    examples: ["React internals", "Next.js router", "Lodash functions"],
    reasoning: "Already tested by library authors",
  },

  trivialCode: {
    examples: [
      "Simple getters/setters",
      "Constants",
      "Type definitions",
      "Pass-through functions",
    ],
    reasoning: "No logic to test, waste of time",
  },

  presentationalComponents: {
    examples: ["Simple buttons", "Icons", "Layout wrappers"],
    reasoning: "Visual regression testing more appropriate",
  },

  configurationFiles: {
    examples: ["webpack.config.js", "next.config.js"],
    reasoning: "Configuration, not logic",
  },

  mockData: {
    examples: ["Fixtures", "Test data", "Storybook stories"],
    reasoning: "Not production code",
  },
};

// Example: Don't test trivial code
// ❌ Don't test this
class User {
  constructor(private name: string) {}
  getName() {
    return this.name;
  } // Trivial getter
}

// ✅ But DO test this
class User {
  constructor(private name: string) {}

  getDisplayName() {
    // Business logic
    return this.name
      .split(" ")
      .map((n) => n.charAt(0).toUpperCase() + n.slice(1))
      .join(" ");
  }
}

Test Priority Matrix

interface TestPriority {
  feature: string;
  businessImpact: "high" | "medium" | "low";
  complexity: "high" | "medium" | "low";
  changeFrequency: "high" | "medium" | "low";
  priority: "P0" | "P1" | "P2" | "P3";
  targetCoverage: string;
}

const testPriorities: TestPriority[] = [
  {
    feature: "Payment processing",
    businessImpact: "high",
    complexity: "high",
    changeFrequency: "low",
    priority: "P0",
    targetCoverage: "100%",
  },
  {
    feature: "User authentication",
    businessImpact: "high",
    complexity: "medium",
    changeFrequency: "low",
    priority: "P0",
    targetCoverage: "100%",
  },
  {
    feature: "Product search",
    businessImpact: "medium",
    complexity: "medium",
    changeFrequency: "medium",
    priority: "P1",
    targetCoverage: "80%",
  },
  {
    feature: "UI themes",
    businessImpact: "low",
    complexity: "low",
    changeFrequency: "high",
    priority: "P3",
    targetCoverage: "30%",
  },
];

// Priority calculation
function calculatePriority(
  businessImpact: number, // 1-10
  complexity: number, // 1-10
  changeFrequency: number // 1-10
): number {
  return businessImpact * 0.5 + complexity * 0.3 + changeFrequency * 0.2;
}

Coverage Configuration

// jest.config.js
module.exports = {
  collectCoverageFrom: [
    "src/**/*.{ts,tsx}",
    "!src/**/*.d.ts",
    "!src/**/*.stories.tsx", // Don't count stories
    "!src/mocks/**", // Don't count mocks
    "!src/**/__tests__/**", // Don't count tests
  ],

  coverageThresholds: {
    global: {
      statements: 70,
      branches: 65,
      functions: 70,
      lines: 70,
    },
    // Critical paths: 90%+
    "./src/services/payment/**/*.ts": {
      statements: 90,
      branches: 85,
      functions: 90,
      lines: 90,
    },
    "./src/services/auth/**/*.ts": {
      statements: 90,
      branches: 85,
      functions: 90,
      lines: 90,
    },
    // Utils: 80%+
    "./src/utils/**/*.ts": {
      statements: 80,
      branches: 75,
      functions: 80,
      lines: 80,
    },
    // UI components: 50%+ (lower bar)
    "./src/components/**/*.tsx": {
      statements: 50,
      branches: 45,
      functions: 50,
      lines: 50,
    },
  },
};

Test Investment ROI

// Calculate ROI of testing
interface TestROI {
  feature: string;
  testingCost: number; // hours
  bugPreventionValue: number; // estimated $ saved
  roi: number; // ratio
}

const testROI: TestROI[] = [
  {
    feature: "Payment processing",
    testingCost: 40, // hours
    bugPreventionValue: 50000, // Could lose $50k revenue
    roi: 1250, // $1,250 per hour invested
  },
  {
    feature: "Authentication",
    testingCost: 20,
    bugPreventionValue: 10000, // Security breach cost
    roi: 500,
  },
  {
    feature: "Theme switcher",
    testingCost: 5,
    bugPreventionValue: 100, // Minor UX issue
    roi: 20,
  },
];

// Focus on high ROI tests
const sortedByROI = testROI.sort((a, b) => b.roi - a.roi);

Pragmatic Testing Strategy

# Testing Strategy Document

## Principles

1. **Business value first**: Test what breaks the business
2. **Edge cases over happy path**: Happy path is obvious
3. **Integration over unit**: Test how pieces work together
4. **Critical flows end-to-end**: User journeys matter most

## Test Types Distribution

- 70% Unit tests (fast, isolated)
- 20% Integration tests (API + DB)
- 10% E2E tests (critical flows only)

## Coverage Goals

- Overall: 70% (pragmatic goal)
- Critical business logic: 90%+
- API endpoints: 80%+
- UI components: 50%+ (user interactions only)

## What NOT to Test

- Third-party libraries
- Trivial getters/setters
- Pure presentational components
- Configuration files
- Mock data and fixtures

## Review Criteria

Before writing a test, ask:

1. What bug would this test prevent?
2. How likely is that bug?
3. How costly would that bug be?
4. Is this already covered by integration tests?

If ROI is low, skip the test.

Team Guidelines

// Code review checklist for test coverage

const reviewChecklist = {
  criticalPath: {
    question: "Does this change affect a critical path?",
    ifYes: "MUST have comprehensive tests (90%+)",
  },

  businessLogic: {
    question: "Is this complex business logic?",
    ifYes: "MUST have unit tests with edge cases",
  },

  apiEndpoint: {
    question: "Is this a new API endpoint?",
    ifYes: "MUST have integration tests",
  },

  uiComponent: {
    question: "Is this a UI component?",
    ifYes: "Optional - test interactions only",
  },

  bugFix: {
    question: "Is this a bug fix?",
    ifYes: "MUST have regression test",
  },
};

Best Practices

  1. Focus on risk: Test what could go wrong
  2. Diminishing returns: 100% coverage has low ROI
  3. Integration over unit: Test behavior, not implementation
  4. Critical paths first: Payment, auth, data integrity
  5. Explicit "don't test": Be intentional about skipping
  6. Review regularly: Adjust targets quarterly
  7. Measure bugs: Track if tests catch real issues

Output Checklist

  • Critical paths identified
  • Layer-specific targets defined
  • "Don't test this" list created
  • Priority matrix established
  • Coverage thresholds configured
  • ROI analysis performed
  • Testing strategy documented
  • Team guidelines defined

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Audits and implements web accessibility (a11y) following WCAG 2.1 guidelines with ARIA patterns, keyboard navigation, screen reader support, and contrast checking. Use when users request "accessibility audit", "a11y review", "WCAG compliance", "screen reader support", or "keyboard navigation".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

sathishssj3/Stereix-Engine22026년 10월 4일 업데이트

Creates Architecture Decision Records documenting key technical decisions with context, alternatives considered, tradeoffs, consequences, and decision owners. Use when documenting "architecture decisions", "technical choices", "design decisions", or "ADRs".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

sathishssj3/Stereix-Engine22026년 10월 4일 업데이트

Designs multi-step agent workflows with tool usage, retry logic, state management, and budget controls. Provides orchestration diagrams, tool execution order, fallback strategies, and cost limits. Use for "AI agents", "agentic workflows", "multi-step AI", or "autonomous systems".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

sathishssj3/Stereix-Engine22026년 10월 4일 업데이트

MUST USE when user wants to 调研/research/搜索/search/查/找/look up anything on the internet — e.g. 全网调研 X / 帮我调研一下 X / 查一下 X / 搜搜 X / 看看大家怎么评价 X / X 上有什么讨论 / research this topic。 Also MUST USE when user mentions any platform or shares any URL/链接: 小红书/xiaohongshu/xhs, Twitter/推特/X, B站/bilibili, Reddit, Facebook, Instagram, V2EX, LinkedIn/领英/招聘/求职/jobs, YouTube, GitHub code search, 小宇宙播客, 雪球/股票行情, RSS feeds, or any web URL. 15 platforms, multi-backend routing (OpenCLI / per-platform CLIs / APIs). Zero config for 6 channels. Run `agent-reach doctor --json` to see which backend serves each platform right now. NOT for: 写报告/数据分析/翻译等内容加工(本 skill 只负责从互联网获取内容); 发帖/评论/点赞等写操作;已有专门 skill 的平台(先用专门 skill)。 【路由方式】SKILL.md 包含路由表和常用命令,复杂场景需按需阅读对应分类的 references/*.md。 分类:search / social (小红书/推特/B站/V2EX/Reddit/Facebook/Instagram) / career(LinkedIn) / dev(github) / web(网页/文章/RSS) / video(YouTube/B站/播客) / finance(雪球/股票)。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

sathishssj3/Stereix-Engine22026년 10월 4일 업데이트

Orchestrates multi-agent AI systems with task delegation, agent communication, shared memory, and workflow coordination. Use when users request "multi-agent system", "agent orchestration", "AI agents", "agent coordination", or "autonomous agents".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

sathishssj3/Stereix-Engine22026년 10월 4일 업데이트

Creates SLO-based alerts and operational dashboards with key charts, alert thresholds, and runbook links. Use for "alerting", "dashboards", "SLO", or "monitoring".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

sathishssj3/Stereix-Engine22026년 10월 4일 업데이트

sathishssj3의 스킬 모두 보기

이 스킬의 문제 신고