Fixtures

Fixtures create runtime dependencies for an example. The source still declares only data; the toolchain owns setup and teardown. A fixture maps declared data to runtime arguments plus side effects, and it lives in the toolchain, never in the source.

Fixture sources compose in order with literal arguments, so http_fixture {...}, 4 produces the arguments [url, 4].

http_fixture

Serves JSON from a temporary local HTTP server and contributes one URL argument:

Fixture `http_fixture`:
```json
{"price": 19.99}
```

The generated code receives a real URL, fetches it, and the judge compares the result. No mocking inside the artifact.

postgres_fixture

Starts an isolated Postgres container, runs setup SQL, and contributes one connection-info object:

Fixture `postgres_fixture`:
```json
{
  "setup_sql": [
    "create table incidents (id text primary key, severity text not null)",
    "insert into incidents (id, severity) values ('INC-1', 'sev1')"
  ]
}
```

This is proven end to end: specs/count_stored_incidents.angl is a DB-backed chapter whose generated artifact connects to the fixture-provided database and passes 3/3 cases:

with psycopg.connect(db["url"]) as conn:
    ...

Why fixtures are the main lever

Each new external dependency a system touches needs a fixture to be testable: db_fixture, file_fixture, time_fixture, queue fixtures, migration fixtures. The fixture library is the main lever for how complex a system Angl can verify. The project becomes much more serious as every external dependency that matters gets a fixture; postgres_fixture is the first real step in that direction.