Also known as: golden files, known-answer tests, reference vectors, KAT
Golden test vectors are stored pairs of a fixed input and its known-correct output, used to pin down exactly what a piece of signal-processing or decoding code is supposed to produce.1 Run the code on the input, compare against the saved “golden” output, and if they differ the test fails — the change is flagged as a regression before it can ship. The term borrows from cryptography and codec standardization, where a known-answer test (KAT) proves an implementation matches the reference bit-for-bit.
How it works
You capture the output of a known-good implementation once — the moment you are confident it is correct — and commit it to the repository as the reference. From then on the test regenerates the output from the same input and asserts equality against the stored copy. The input can be a synthetic IQ burst, a short off-air capture, or an abstract byte array; the golden side can be decoded bits, demodulated audio, filter coefficients, or a measured metric such as SNR or EVM.
The comparison comes in two flavors:
- Bit-exact — the output must match byte-for-byte. Appropriate for integer DSP, forward-error-correction decoders, vocoders, and cryptographic primitives, where the standard defines one right answer.
- Tolerance-based — floating-point results are compared within an epsilon, and quality metrics are asserted to stay above a threshold (e.g. “demod SNR ≥ 19 dB on this capture”), guarding against silent degradation rather than demanding an identical number.
When the code legitimately changes behavior, you regenerate and review the golden files — the diff in the fixture is itself a reviewable record of what the change did to the output, which is the discipline’s real value.
In practice
Golden vectors live inside an ordinary unit-test suite and are the natural companion to testing without hardware: the fixed input is a file, the golden output is a file, and neither needs a radio. The standards world supplies ready-made vectors — DES and AES ship official KATs, and speech codecs like AMBE/IMBE and Codec 2 publish reference input/output pairs so independent decoders can prove conformance.
Two hazards deserve care. First, an incorrect golden file locks in a bug: the vector is only as trustworthy as the moment it was captured, so it should be generated from a verified reference or a hand-computed answer, not from whatever the code happened to emit. Second, over-strict bit-exact comparison on floating-point pipelines produces brittle tests that fail across compilers or CPUs — reserve exactness for integer and specification-defined outputs, and use tolerances elsewhere.
Relevance to SDR
Golden vectors are how DSP correctness is kept honest over time. A digital filter, a Viterbi decoder, a CRC check, or a full protocol framer each has a definable right answer for a given input, so each can be pinned. Regenerating the golden output and eyeballing the diff is often the fastest way to understand the effect of a refactor on a numerically dense function.
GopherTrunk relies on this pattern throughout its decode chain. Its file-replay tests assert concrete, checked-in expected results — decoded control messages from a given capture, and demodulation quality metrics that must not regress (a specific capture is pinned to lock at roughly a known demod SNR and EVM, and a companion test asserts the decode chain reaches the receiver at the same in-channel SNR whether the file is processed natively or resampled). Those are golden vectors in spirit: a known input, a known-correct measured output, and a failing test the instant a change moves the number. Combined with forward-error-correction known-answer tests and synthetic inputs, they let the whole receiver be regression-tested with no transmitter present.
Sources
-
Test vector — Wikipedia, on fixed input/expected-output pairs used to validate implementations against a specification. ↩