What do conformance tests establish?

Turn promises into executable checks

AFS’s runProviderTests() accepts a provider factory, a resource structure and operation-specific fixtures. Shared suites can then examine different implementations against common contracts. The structure describes resources; capability declarations determine additional obligations.

Declaring conditional writes, for example, requires an ifMatch fixture. The relevant contract includes an independent provider object targeting the same backing store, so a lock inside one object cannot be the only evidence.

// Fixture outline: fill in a real provider and its actual structure.
runProviderTests({
  name: "ReportProvider",
  createProvider: () => new ReportProvider(),
  structure: { root: { name: "", children: [
    { name: "report", content: { title: "Prepare the keynote", status: "draft" } }
  ] } }
});

Passing has a scope

A test result concerns a version, fixture and environment. It does not automatically establish external-service availability, cross-process concurrency, deployment permissions or complete business behavior.

Connect fixtures to the actual implementation. Special fake responses that satisfy the test instead of exercising the provider do not establish compatibility. Extend the checked behavior when adding capabilities.

Three terms in the example

A provider factory is a function that creates a provider instance, here () => new ReportProvider(). A fixture supplies known test data and expectations: which resources exist and what reading them should return.

The minimal structure above establishes resource and read checks. It supplies no conditional-write fixture and proves neither writes nor concurrency. Conditional writes allow an update only while the resource still matches an expected version. Declaring that capability requires an additional ifMatch fixture, including another provider instance using the same backing data. Cross-process guarantees require corresponding cross-process checks.