Kjell Tore Guttormsen
9dd86b1b18
TDD step 8: three golden cases per the §11 format (manifest.json, fixture/, ingested-at.txt, expected-bundle/) — ingest-golden-file and ingest-golden-sql are the conformance MUSTs; ingest-golden-http documents and exercises the optional extension against mock payloads. The conformance test re-materializes each case into a fresh directory and compares byte for byte; offline and credential-free (the sql fixture is a committed database file, http never opens a socket). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QeqhJpYQyghASjiJo5EhGg
1.2 KiB
Golden extractions (ingest-spec §11)
One directory per case, ingest-golden-{source type}/, each containing:
| Entry | Meaning |
|---|---|
manifest.json |
The manifest under test. |
fixture/ |
The source content (CSV catalogue, sqlite database, or mock payloads). |
ingested-at.txt |
The fixed timestamp, one line, §5 format. |
expected-bundle/ |
The expected materialized bundle, compared byte for byte. |
ingest-golden-file and ingest-golden-sql are the conformance MUSTs. The
http source type is an OPTIONAL extension point (spec §1); this repository
implements it, and ingest-golden-http exercises it against the mock payloads
in its fixture/ directory — the conformance suite never opens a socket and
runs without credentials (§11). For the sql case, the test sets the
OKF_GOLDEN_SQL_DB environment variable to the fixture database path; for the
http case, the injected mock transport serves fixture/{query path}.
The suite (tests/test_golden.py) re-materializes each case into a fresh
directory and compares the result against expected-bundle/ file by file,
byte for byte — the load-bearing golden-regression seam (§11).