Skip to main content

failure-classify

Group failing tests by naming convention so a real assertion failure is not hidden among tests that exist to verify a system rejects something. Use after running the test suite and before reading the report.

Source facts

Repository
majiayu000/test-loop
Last source activity
June 5, 2026 at 02:38
Detected SKILL.md language
English
Stars
0
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
failure-classify
description
Group failing tests by naming convention so a real assertion failure is not hidden among tests that exist to verify a system rejects something. Use after running the test suite and before reading the report.
metadata
{"type":"project","language":"any","inputs":"test runner log path, optional language pattern","outputs":"failures_by_class counts, failures_grouped listing, exit code"}
# failure-classify Triage failing tests so a real regression does not get lost among tests that are *expected* to fail (because they verify that the system rejects bad input). ## When to use - After every test run that produced at least one failing test. - Before triaging a CI failure manually. - In the report-render skill's input pipeline. Do **not** use this skill to decide whether a regression is "important enough to fix". That is a human judgement. The skill only sorts. ## Inputs | Name | Required | Default | Description | | --- | --- | --- | --- | | `log_path` | yes | none | Path to the test runner's output. The skill scans for `✘` lines (or `FAIL` lines, depending on the language pattern). | | `language` | no | `swift` | One of `swift`, `python`, `go`, `rust`. Picks the line-extraction regex and the classification patterns. | | `self_test` | no | `false` | When `true`, runs the skill's internal unit tests and exits. Use after editing the classification rules. | ## Output | Channel | Content | | --- | --- | | stdout | A JSON object with three keys: `failures` (deduplicated list of failing test names), `failures_by_class` (counts per class), `failures_grouped` (test names bucketed by class). | | exit code | `0` on success regardless of test outcomes. `1` if the log could not be read. `2` on self-test failure. | ## Classification taxonomy Seven classes. Order matters: the first matching pattern wins. A test name that matches no pattern falls into `ASSERTION_FAILURE` by default. | Class | Meaning | Trigger keyword (regex fragment) | | --- | --- | --- | | `EXPECTED_FAILURE` | the test verifies the system rejects something | `Reject`, `Refuse`, `ErrorContains`, `WithInvalid`, `DataCorrupted`, `InvalidDuration`, `LongSessionOnBattery` | | `IO_BACKEND` | the test exercises a system API (IOKit, libusb, raw sockets) | language-specific prefix, e.g. `powerAssertion*` in Swift | | `ENVIRONMENT_ERROR` | the test depends on a live system reading | `PowerSourceMonitor`, `BluetoothState`, `NetworkLink` | | `TEST_SCAFFOLD` | the test depends on a missing setup artifact | reserved; no patterns in v0.1 | | `ASSERTION_FAILURE` | real bug | default bucket | | `PRECONDITION_MISSING` | required env var / file is missing | `requireEnv`, `skipIf` markers | | `UNKNOWN` | could not classify | fallback (rare; usually means the runner produced an unexpected line format) | ## Algorithm 1. **Extract** failing test names from the log. Swift Testing emits two `✘` lines per failing test (one for the issue, one for the summary). The skill deduplicates while keeping the first-seen order. 2. **Classify** each name against the patterns, first-match-wins. 3. **Emit** JSON: list, counts, grouped. ## Worked example (Swift) Log: ``` ✔ Test foo() passed after 0.001 seconds. ✘ Test barRejectsZero() failed after 0.001 seconds with 1 issue. ✘ Test bazShouldBehave() failed after 0.001 seconds with 1 issue. ``` Output: ```json { "failures": ["barRejectsZero", "bazShouldBehave"], "failures_by_class": { "EXPECTED_FAILURE": 1, "ASSERTION_FAILURE": 1 }, "failures_grouped": { "EXPECTED_FAILURE": ["barRejectsZero"], "ASSERTION_FAILURE": ["bazShouldBehave"] } } ``` The first test is an expected-failure pattern (`Rejects`). The second is a real regression candidate. ## Anti-patterns - **Treating `EXPECTED_FAILURE` as a green light.** A failure classified as `EXPECTED_FAILURE` still failed. The classification only means the failure is the test's *purpose*, not that the system under test behaves correctly. The test author must read the message. - **Adding patterns that match everything.** Patterns are first-match wins. A pattern like `.*` would swallow every test into one bucket. - **Assuming a runner that is not in the language list still works.** The v0.1 patterns cover Swift Testing only. For other runners, the user must extend the patterns and add a self-test. ## Cross-references - [report-render](../report-render/SKILL.md) — consumes the JSON output and embeds it in the Markdown report. - [drill](../drill/SKILL.md) — uses this skill to verify the loop reacts to a real failure. - [drift-check](../drift-check/SKILL.md) — the previous step in the loop.
View on GitHub