The OapiCodemode.SpecStore conformance suite.

A store is only interchangeable if the contract is tested once and run against every implementation, so the tests live here — in lib/, not test/ — and downstream repos run the same file against their own store:

defmodule MyApp.SpecStore.EctoConformanceTest do
  use OapiCodemode.SpecStoreCase, async: true

  defp store_fixture, do: {MyApp.SpecStore.Ecto, MyApp.Repo}
end

The using module supplies store_fixture/0, returning an empty {module, handle} store. It is called inside each test, so a store that needs per-test setup (a checked-out sandbox connection, a fresh table) can build it there.

This module brings ExUnit.Case in with the options passed to use. A store whose repo has its own case module can compose the two — the outer template's setup still runs, and its helpers are still in scope:

defmodule MyApp.SpecStore.EctoConformanceTest do
  use MyApp.DataCase, async: false
  use OapiCodemode.SpecStoreCase

  defp store_fixture, do: {MyApp.SpecStore.Ecto, MyApp.Repo}
end

Put the ExUnit.Case options (async:) on the outer use, which is the one that registers the case; the inner use then joins it.

Two things the suite asks of an implementation that are easy to miss:

• A spec id it never issued must come back {:error, :not_found}, not raise — even one shaped nothing like its own ids. Refs outlive the thing that made them (a registry entry survives a DB restore), so a store that casts its ids needs to fail the cast softly.
• The concurrency case calls put/2 from spawned processes. A store needing per-process setup — an Ecto sandbox connection — should run the suite without async: true and put the sandbox in shared mode in store_fixture/0.

What is covered, from the design's testing section: the decompose → put → meta/index/operation/components round-trip, put of a known hash, a bumped decomposer_version coexisting with the old projection, concurrent put of the same hash, pointer/4's byte budget and its array walk, missing component names absent rather than fatal, :not_found for an unknown ref or operation id, and the one filtering rule a store must not apply itself:

What is not covered here, and has to be covered by the store:

• A real put/2 race. Under a shared Ecto sandbox the eight concurrent puts all borrow one connection, so they serialise and the second putter reads the first one's committed rows. That checks the idempotent path; it does not reach the unique-hash-violation-then- re-read path, which needs genuinely simultaneous transactions — Ecto.Adapters.SQL.Sandbox.unboxed_run/2, or per-task connection ownership. An Ecto store owes its own race test.
• Stale-projection rebuild. "The spec is there but the projection is missing, so build it on demand" is unreachable through this surface: put/2 is the only writer and it always writes both. A store that can end up in that state — a migration that drops projections, an index_bytes backfill — has to reach behind its own API to set it up, so the test belongs with the store.