dsp-audio-metrics

Appearance

Coverage gate & CI ​

Every merged PR must keep the test suite at strict coverage thresholds. The gate runs on Node 22 in publish.yml and fails the build if any file drops below:

MetricThreshold
Lines95%
Branches90%
Functions95%

The current suite sits at 100% lines / 91% branches / 100% functions. Coverage is measured with Node's built-in --experimental-test-coverage against src/** only — CLI/CI plumbing (bin/, script/) is excluded because it is itself unit-tested through the same suite.

bash
npm run lint          # eslint on src, bin, script, test
npm test              # node --test (native runner, no framework)
npm run test:coverage # print the coverage report
npm run test:coverage:ci  # coverage report WITH the gate thresholds (fails on drop)

Why a coverage gate and not golden files ​

Golden-file audio fixtures (a reference WAV and a fixed expected number) are the obvious way to test a DSP library — and the wrong one here. A fixture pins your implementation's bugs: regenerate the reference and the test changes meaning. Instead, dsp-audio-metrics pins the spec with analytically-known signals:

  • a full-scale 1 kHz sine is -3.01 LUFS by the definition of the K-weighting + 0.691 offset;
  • halving amplitude is exactly -6.02 LU (power halves = 10*log10(0.5));
  • true peak of a full-scale sine is 0 dBTP;
  • silence is -Infinity, an unmeasurable LRA is NaN;
  • 44.1 kHz resampled equals 48 kHz native within 0.1.

If any of these drift, it is the code that is wrong, not the fixture.

Branch coverage, the honest bit ​

The package goes to lengths to avoid untestable branches: resamplePoly short-circuits the identity ratio, gating loops converge (they always do in <10 iterations), and every if in the resampler has a reachable case in the suite. Where a branch is genuinely defensive (e.g. a p >= up clamp that floating-point rounding can trigger), the tests force it.