/test-tagging

name: test-tagging
description: >
  Classifies existing tests by standard traits and reports their distribution.
  USE FOR: tagging all tests with category attributes, categorizing/tagging/
  labeling each
  test, compare happy vs error paths, audit the test mix, describe coverage shape
  by test type, or tag then verify the project builds. Read bodies when names
  mislead. Apply canonical attributes; otherwise report only. DO NOT USE FOR:
  requests owned by test-anti-patterns, coverage-analysis, crap-score,
  test-gap-analysis, code-testing, or migration skills.
license: MIT

Test Trait Tagging

Analyze an existing test suite in any supported language and apply a standardized set of trait tags to each test method, giving teams visibility into their test distribution (positive vs. negative, critical-path coverage, smoke tests, etc.).

> **Language-specific guidance**: Read the caller-provided or runtime-listed > `test-analysis-extensions` catalog and its matching language file. > The helper is reference-only, not an invocable skill. If absent, > continue with the built-in framework table below and report the limitation.

When to Use

• Auditing a test project to understand the mix of test types
• Adding trait attributes to untagged tests
• Generating a summary report of trait distribution across a test suite
• Reviewing whether critical paths have sufficient coverage

When Not to Use

• Writing new tests from scratch (use `code-testing` for any language, or `writing-mstest-tests` for MSTest)
• Running or filtering tests (use `run-tests` for .NET; equivalent native runners elsewhere)
• Migrating between test frameworks
• General quality, smell, flakiness, or assertion audits (use `test-anti-patterns` or the matching analysis skill)
• Diagnostic .NET executed line/branch/Cobertura interpretation or project-wide CRAP risk (use `coverage-analysis`); raw coverage collection (use `run-tests` for .NET, native tooling otherwise)
• CRAP analysis for a named method, class, or file (use `crap-score`)
• Behavioral gaps where a test would survive broken production logic (use `test-gap-analysis`)

Inputs

| Input | Required | Description | |-------|----------|-------------| | Test project or files | No | Path to the test project, folder, or specific test files. Discover from the current workspace when omitted. | | Scope | No | Infer from the verb: `tag`/`apply` edits, `audit`/`classify`/`report` is report-only, and `both` applies only when both are requested. If ambiguous, default to `audit` to avoid unrequested edits. Frameworks declared `report-only` always emit a report; `convention-based` frameworks edit only after the user confirms the convention. | | Framework | No | Auto-detected. Override when detection fails. |

Trait Taxonomy

Use exactly these trait names and values. Do not invent new trait values outside this table.

| Trait Value | Meaning | Heuristics | |-------------|---------|------------| | `positive` | Verifies expected behavior under normal/valid conditions | Asserts success, valid output, expected state, no exceptions for valid input | | `negative` | Verifies correct handling of invalid input, errors, or edge cases | Asserts exceptions, error codes, validation failures, rejects bad input | | `boundary` | Tests limits, thresholds, empty/null/None/nil inputs, min/max values | Operates on `0`, `-1`, `int.MaxValue` / `sys.maxsize` / `Number.MAX_SAFE_INTEGER` / `math.MaxInt64` / `i32::MAX`, empty string, null/None/nil/undefined, empty collection, boundary of valid range | | `critical-path` | Core workflow that must never break; breakage blocks users | Tests the primary success scenario of a key public API or user-facing feature | | `smoke` | Quick sanity check that the system is operational | Fast, no complex setup, verifies basic wiring (e.g., service resolves, endpoint returns 200) | | `regression` | Reproduces a specific previously-reported bug | References a bug ID, issue number, or describes a fix in its name or comments | | `integration` | Crosses process, network, or persistence boundaries | Uses real database, HTTP client, file system, external service, or multi-component setup | | `end-to-end` | Full user workflow spanning the entire application stack | Exercises a complete scenario from entry point to final result, distinct from single-boundary `integration` | | `performance` | Validates timing, throughput, or resource consumption | Asserts on elapsed time, memory, allocations, or uses benchmark harness (BenchmarkDotNet, pytest-benchmark, benchmark.js, JMH, `go test -bench`, criterion.rs, XCTMetric, kotlinx-benchmark, Google Benchmark) | | `security` | Verifies authentication, authorization, input sanitization, or secrets handling | Tests for SQL injection, XSS, CSRF, unauthorized access, token validation, permission checks | | `concurrency` | Validates thread safety, parallelism, or async correctness | Uses `Task.WhenAll` / `Parallel.ForEach` / `SemaphoreSlim` (.NET); `asyncio.gather` / `threading.Lock` / `multiprocessing` (Python); `Promise.all` / worker threads (JS/TS); `CompletableFuture` / `ExecutorService` / `synchronized` (Java); `go func` / `sync.WaitGroup` / `sync.Mutex` / `chan` (Go); `Mutex` / `Thread.new` (Ruby); `tokio::spawn` / `Arc<Mutex<_>>` / `crossbeam` (Rust); `DispatchQueue` / `actor` (Swift); `coroutineScope` / `Mutex` (Kotlin); `Start-Job` / `RunspacePool` (PowerShell); `std::thread` / `std::mutex` (C++); reproduces race conditions | | `resilience` | Tests retry logic, timeouts, circuit breakers, or graceful degradation | Asserts behavior under transient failures, network drops, or service unavailability (e.g., Polly, tenacity, p-retry, resilience4j, hystrix, opossum, retry-go) | | `destructive` | Mutates shared or external state that is hard to roll back | Deletes records, drops resources, modifies global config -- useful for CI isolation decisions | | `configuration` | Verifies settings loading, defaults, environment behavior | Te