domains / families / software-engineering / test-tagging

test-tagging

separate

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.

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`)

Skill page

Source