test(search-pipeline): cover registry-sourced extraction against a register-shaped fixture

[ddeboer]

The registry-sourced stages (#695) shipped with unit tests over hand-built stubs and nock. Nothing exercised them against register-shaped data, or against a real SPARQL engine, so the three properties the design rests on were argued in review rather than pinned by a test.

The fixture

register-sample.trig is modelled on the NDE Dataset Register: each registration is crawled into a named graph called after its dataset IRI, and is self-contained in it – the publisher’s foaf:name and its foaf:Organization type sit inside the dataset’s own graph. Two registrations, so a run scoped to one must not see the other; plus a registrations graph holding the schema:Dataset stubs that a never-crawled registration leaves behind.

The test

Both root types run end to end against a local SPARQL endpoint (port 3009) with no explicit readers, so each stage defaults to the generated Extraction CONSTRUCT – proving the generator, the graph scoping, the framing and the projection agree, rather than testing them in isolation.

• the registration in hand projects in full, publisher hop included;
• another registration’s graph is never reached;
• scoping follows whichever dataset is in hand;
• a registration that was never crawled cannot be selected – dcat:Dataset inside the dataset’s own graph structurally excludes the schema:Dataset stubs rather than filtering them out afterwards.

Two things that keep it honest

The dataset’s own distribution points at an unreachable URL, so a stage that ignored sourceFor fails to connect rather than quietly passing.

Every absence assertion is paired with what the pass did produce. Removing the graph scoping leaves the file endpoint’s default graph empty, so a bare not.toContain would pass vacuously – verified by mutating registrySource to drop the scoping: two of four tests initially survived it, and all four fail after the pairing.