home / skills / laurigates / claude-plugins / test-tier-selection

test-tier-selection skill

/testing-plugin/skills/test-tier-selection

This skill guides test tier selection automatically based on change scope, optimizing testing effort and feedback speed for unit to end-to-end suites.

npx playbooks add skill laurigates/claude-plugins --skill test-tier-selection

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.1 KB
---
model: opus
created: 2025-12-16
modified: 2025-12-16
reviewed: 2025-12-16
name: test-tier-selection
description: Automatic selection of appropriate test tiers based on change scope. Guides unit tests for small changes, full suite for larger changes. Use when running tests, discussing testing strategy, or after code modifications.
allowed-tools: Bash, Read, Glob, Grep
---

# Test Tier Selection

Automatic guidance for selecting appropriate test tiers based on change context and scope.

## Test Tier Definitions

| Tier | Duration | Scope | When to Run |
|------|----------|-------|-------------|
| **Unit** | < 30s | Single function/module | After every code change |
| **Integration** | < 5min | Component interactions | After feature completion |
| **E2E** | < 30min | Full user flows | Before commit/PR |

## Decision Matrix

### Change Type → Test Tier

| Change Type | Unit | Integration | E2E |
|-------------|------|-------------|-----|
| Single function fix | Required | Skip | Skip |
| New feature (1 file) | Required | Required | Skip |
| Multi-file feature | Required | Required | Required |
| Refactoring | Required | Required | Optional |
| API changes | Required | Required | Required |
| UI changes | Required | Optional | Required |
| Bug fix (isolated) | Required | Optional | Skip |
| Database changes | Required | Required | Required |
| Config changes | Required | Required | Optional |

## Escalation Signals

**Escalate to Integration when:**
- Changes span multiple files
- Business logic affected
- Service boundaries modified
- Database queries changed

**Escalate to E2E when:**
- User-facing features modified
- Authentication/authorization changes
- Critical path functionality
- Before creating PR

## Commands by Tier

```bash
# Tier 1: Unit (fast feedback)
/test:quick

# Tier 2: Integration (feature completion)
/test:full --coverage

# Tier 3: E2E (pre-commit)
/test:full
```

## Agent Consultation Triggers

**Consult `test-architecture` agent when:**
- New feature module created
- Coverage drops > 5%
- > 3 flaky tests detected
- Framework questions arise
- Test strategy needs adjustment

**Consult `test-runner` agent when:**
- Need test execution with analysis
- Multiple failures to diagnose
- Want concise failure summary

**Consult `system-debugging` agent when:**
- Integration test failures with unclear cause
- Environment/timing issues
- Flaky tests related to concurrency

## Quick Reference

### After Small Change
```
1. Run /test:quick
2. If pass: Continue working
3. If fail: Fix immediately
```

### After Feature Completion
```
1. Run /test:full --coverage
2. Check coverage targets met
3. If gaps: /test:consult coverage
```

### Before Commit/PR
```
1. Run /test:full
2. All tiers must pass
3. Review coverage report
```

### For New Features
```
1. /test:consult new-feature
2. Write tests (TDD)
3. Run /test:quick during development
4. Run /test:full before PR
```

## Activation Triggers

This skill auto-activates when:
- User mentions "test", "run tests", "testing"
- After code modification by Claude
- During TDD workflow
- When `/test:*` commands invoked
- When discussing test strategy

Overview

This skill provides automatic guidance to select the appropriate test tier based on the scope of a code change. It recommends when to run unit, integration, or end-to-end tests and offers escalation signals and commands for each tier. Use it to streamline testing decisions during development, reviews, and CI preparation.

How this skill works

The skill inspects change scope, affected files, and change type to map to a test tier decision matrix. It triggers guidance automatically on test-related mentions, after code modifications, or when test commands are invoked. It suggests concrete commands for quick unit feedback, integration runs with coverage, and full E2E pre-commit runs.

When to use it

  • After a small code change or single-function fix to decide if quick unit tests suffice
  • When finishing a feature to determine integration and coverage runs
  • Before commit or PR to ensure full-suite and E2E checks pass
  • When debating test strategy or encountering flaky tests
  • When database, API, or UI changes may affect multiple layers

Best practices

  • Run unit tests (<30s) after every code change for fast feedback
  • Escalate to integration if changes span multiple files or affect business logic
  • Run E2E before PRs for user-facing, auth, or critical-path changes
  • Use /test:quick for development, /test:full --coverage for feature completion, and /test:full before commits
  • Consult specialized agents for architecture, runner analysis, or system debugging when signals appear

Example use cases

  • Single-function bug fix: run /test:quick, fix immediately if failing
  • New one-file feature: run unit and integration tests, skip E2E until PR
  • Multi-file feature or API change: run unit, integration, and full E2E before PR
  • Refactor spanning modules: run unit and integration; consider E2E if core flows touched
  • Coverage drop or >3 flaky tests: consult the test-architecture or test-runner agents

FAQ

When should I always run unit tests?

Run unit tests after every code change and on every commit for fast feedback and regression prevention.

What signals force escalation to E2E?

Escalate to E2E for user-facing changes, authentication/authorization updates, critical-path changes, or before creating a PR.