跳到正文
cccskills
免费在 GitHub 公开

test-audit

Decide whether a Pulp test earns its place — before writing it, when reviewing one, or when sweeping a subsystem for low-value, duplicated, or mis-routed tests. Applies a four-question authoring gate, a junk-pattern list, a retention bar, and an evidence template for any deletion, and routes kept tests to the right lane (required gate, pr-fast, slow, nightly). Handles "should I add a test for this", "is this test useful", "audit these tests", "reduce test time", "which tests can go", and "move toward functional tests".

中文简介正在准备中。当前显示原文说明。

查看安装方法

包含的文件(1)

  • SKILL.md8.6 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Test Audit

The goal is confidence per minute of gate time, not a deletion count and not a coverage number. Most of Pulp's suite is real tests; its waste is mostly duplication across layers, oversized grids, and tests running on a lane that does not need them. Audit with that prior.

Adapted from OpenClaw's test-audit skill (https://github.com/openclaw/openclaw/blob/main/.agents/skills/test-audit/SKILL.md), with Pulp's lanes, harnesses, and retention rules.

This complements, and does not relax, CLAUDE.md's "Tests ship with fixes": a fix still lands with its test. This skill decides which test — one, at the boundary that owns the behavior, functional by default.

Modes

ModeWhenOutput
Authoringbefore adding or changing any testpass the gate below, or don't add it
Auditreviewing a PR's tests, or a focused sweepa short list of high-confidence candidates with evidence
Campaignpruning one subsystem's suiteone owner-boundary PR per subsystem, evidence per deletion

Audit and campaign start read-only: record evidence before editing anything.

Authoring gate — answer all four before adding a test

  1. What behavior, invariant, or contract does it protect? Name it in the test name as an observable outcome ("the tom's pitch dive finishes before the note does"), not as the function it calls.
  2. What realistic regression makes it fail? If you cannot describe the bug, the test is decoration.
  3. Why doesn't existing coverage already catch that? Each contract has one primary owner at the strongest boundary. A second layer needs its own distinct risk. Prefer adding a row to an existing table-driven case over a new case.
  4. Does it need a seam no real caller uses? Then test at the real boundary instead of adding a test-only accessor.

Then prove it can fail: break the fix and watch the test go red with tools/scripts/confirm_failure.sh (see CLAUDE.md, "Confirm the failure"). Before acting on a NOT CONFIRMED or INCONCLUSIVE verdict, read the phase log it prints (test output (broken|baseline|restored): <path> and its tail): it shows whether the test actually ran the case you meant, so a bad verdict is checked against evidence before a good test gets rewritten. --break runs with the file path appended, and a --test that starts with sh needs --subject <binary>.

Junk patterns

A match fails the gate unless the test names an independent contract the retention bar keeps.

  • No assertions, or assertions that cannot fail.
  • Self-comparison: two identically configured objects compared to each other (the guard under test is never exercised).
  • Expected values produced by the code under test (goldens regenerated from the renderer, impulse values snapshotted from the filter itself) — change detection, not correctness.
  • A test-local subclass or mock that implements the behavior being asserted.
  • Capability tests that restate declared flags or ID constants instead of exercising delivery.
  • Exact string greps over source, docs, or generated code, where a behavior-level assertion (layout geometry, render output, round trip) exists.
  • The same contract re-asserted at every layer (proof, authoring, control, runtime) with no layer-specific risk.
  • Near-identical cases that differ by one input — merge into a table.
  • Names that promise more than the inputs exercise.
  • Per-element REQUIRE inside a sample loop — compare whole buffers once.
  • Phase or ticket breadcrumbs in names or tags (already forbidden; see the code-comments skill).

A test that breaks under a behavior-preserving refactor is implementation- coupled. In authoring, rewrite it at the owning boundary. In an audit it is suspect, not automatically deletable.

Retention bar — keep these

  • Public API, plugin-format adapter, protocol, state serialization / migration, and file-format contracts.
  • Real-time safety, threading and lock-free handoff invariants.
  • Platform behavior (clipboard, dialogs, audio devices, screenshots).
  • Credible regressions — a bug that actually shipped or nearly did.
  • Functional end-to-end behavior (see templates below).
  • Static drift / registry guards that are the cheapest independent check of a real invariant (two real sources agree). Being static or slow is not a reason to delete.

A retained test that fails on the base branch is a possible product bug: fix it at the owner, don't delete it.

Prefer functional tests

Drive the public path, observe the outcome a user or host would observe, and assert a stated law with a derived tolerance and a built-in control.

AreaShapeExisting example
Format adaptersrender directly and through the adapter over a sample-rate × block-size sweep; require equalitytest/test_vst3_audio_parity.cpp
Widgetssimulate_click / simulate_drag → state change + callbacktest/test_widgets.cpp
Design importlive source vs baked native layout snapshottest/test_design_import_native_materializer.cpp
DSPrender through process_block or RenderScenario; measure with the shared analyzers; include a no-effect controlFDN reverb, drum-voice, and kick suites
CLIshell out to the built binary; assert exit code + outputtest/test_control_sample_region_e2e.cpp

Load the audio-harness skill before choosing DSP acceptance gates.

Grid economics

Most DSP runtime sits in a few cases with oversized grids. Before accepting a slow test, ask whether a smaller grid catches the same regression:

  • One point per behavior regime, not every sample rate × every setting.
  • Short renders: reset leaks and block-partition dependence show up in seconds.
  • Build expensive fixtures (baked graphs, baselines) once per case, not per probe.
  • Keep an exhaustive sweep if it has value — tag it [slow] so it leaves the required gate.

Routing: which lane a kept test belongs in

Labels decide lanes; docs/guides/test-lanes.md is the source of truth.

  • no label — required macos gate (merge queue runs the full suite).
  • pr-fast — deterministic static contracts that also run on the PR head.
  • slow / performance / bench / quality-lab / validation — off the required gate. Before moving a test there, name what still enforces it: the nightly is informational, not a gate, so a test that must block needs an affected-path selector (see "Affected slow proofs" in test-lanes.md).

RUN_SERIAL and PROCESSORS 8 tests run alone and set the floor on the test step's wall-clock. Don't add either without a stated reason, and don't strip an existing one without reading why it was set.

Measure against real gate timing, not a local Debug run. The macos job log prints every test's time (Test #N: <name> ... Passed <s> sec); local Debug costs can be an order of magnitude higher and misrank tests.

Candidate evidence (required before any deletion)

Record for each candidate; a missing field blocks the deletion.

  • Test name and file:line.
  • The failure it can detect.
  • Non-test callers of the covered code.
  • The stronger remaining proof at the owner boundary (or why none is needed).
  • Why the test exists — git log -L or the originating commit.
  • What production or test-support code the deletion unlocks.
  • Risk, and the focused validation command.

Edit shape

  • One coherent owner-boundary batch per PR.
  • Delete test-only accessors and wrappers along with the tests that kept them alive.
  • Move a retained regression to its canonical owner rather than keeping copies.
  • Don't add replacement tests that restate the implementation, and don't delete uncertain candidates to inflate a count.
  • Report test LOC and production LOC separately in the PR description.

Validation

  1. Build and run the owner's and siblings' test targets (ctest --test-dir build -R <pattern>; pair any "0 tests" result with a positive control — ctest -R exits 0 on no match).
  2. For a removed string grep, run the tool or check that owns the real contract.
  3. tools/scripts/gates.sh origin/main.
  4. Run the inline architectural + adversarial review before the PR.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

aax

免费

Optional AAX support for Pulp, including developer-supplied Avid SDK setup, CMake enablement, DigiShell/AAX Validator workflows, and local AAX builds on macOS or Windows.

中文简介正在准备中。当前显示原文说明。

Generous-Corp/pulp222026年10月19日 更新

Configure, implement, and test Pulp's optional desktop Ableton Link tempo-sync adapter while preserving the developer-supplied SDK, licensing, realtime, latency-compensation, and no-install boundaries.

中文简介正在准备中。当前显示原文说明。

Generous-Corp/pulp222026年10月19日 更新

Maintain Pulp's installed design-time agent capability manifest and public-surface ledger. Use when adding, removing, renaming, or materially changing public audio, MIDI, signal, timebase, or sequence APIs; registering a new algorithm for generators; changing capability support or deprecation state; or repairing agent-capabilities freshness, schema, fingerprint, tombstone, or installed-SDK tests.

中文简介正在准备中。当前显示原文说明。

Generous-Corp/pulp222026年10月19日 更新

android

免费

Android platform development for Pulp — NDK cross-compilation, Oboe audio, Dawn/Skia GPU rendering, JNI bridge, touch interaction, emulator workflows, and end-to-end smoke validation. Covers build, deploy, debug, and the gotchas discovered during bringup.

中文简介正在准备中。当前显示原文说明。

Generous-Corp/pulp222026年10月19日 更新

ara

免费

Optional ARA support for Pulp, including developer-supplied ARA SDK setup, CMake enablement, adapter companion APIs, validation, and ARA-aware plugin implementation guidance.

中文简介正在准备中。当前显示原文说明。

Generous-Corp/pulp222026年10月19日 更新

The measurement surface for ALL Pulp DSP and audio-pipeline work — read it BEFORE writing or gating DSP, not only when something already sounds wrong. Covers the C++ harness (signal generators, metrics, assertions, RenderScenario, contracts), the offline Audio Doctor (magnitude/frequency response, THD/THD+N, phase/group delay), and their Python sibling the Audio Quality Lab (tools/audio/quality-lab — null residual + alignment, LTAS log-spectral distance, spectral flux/centroid, HNR, Theil-Sen drift slope, Kaiser-sinc resampling, license-guarded corpus, regression-net ratchet). TRIGGER on AUTHORING work — "build/design an oscillator/filter/synth/effect", "add a DSP module", "what should the acceptance gate be", "how do I measure aliasing / anti-aliasing / alias floor", "null against a reference", "is this DSP correct", "choose a tolerance", "golden/regression corpus for audio", "measure drift or jitter", "A/B two renders" — AND on DEBUGGING work — "is there sound / no audio / I hear nothing", "does this filter/compressor/synth/delay produce the right signal", "prove the DSP / prove the contract", "measure the frequency response", "what's the THD / is it distorting", "what's the group delay / phase response / measured latency", "magnitude response curve", "render a test tone and assert", "audio regression", "64-frame works but 128 is silent", "sample-rate change pitch-shifted it", "describe what's in this buffer", "audio doctor", "compare before/after a DSP refactor". Reach for this BEFORE hand-rolling any FFT, null test, alias measurement, pitch tracker, or golden-render script — most of it already exists in one of the two lanes. Test/tool layer over HeadlessHost — deterministic, no audio device, no speakers. Off the realtime thread entirely.

中文简介正在准备中。当前显示原文说明。

Generous-Corp/pulp222026年10月19日 更新

查看 Generous-Corp 的全部技能

报告此技能的问题