fixtures

name	fixtures
description	Guides authoring, organizing, and referencing test fixtures across the engine repo. Use when creating new fixtures, writing tests that depend on fixtures, or deciding what should be checked into git.

Fixtures

What fixtures are

Fixtures are static input files — HTML, SVG, CSS, JSON, .grida, font binaries, images, text samples — used as deterministic inputs to rendering, parsing, and I/O tests. They exist so that tests are reproducible, self-contained, and don't depend on external services or generated data.

Why we keep them

• Regression detection — render the same input, compare the output.
• Spec coverage — each fixture maps to a specific feature or property being tested (one concept per file).
• Onboarding — new contributors can see exactly what the renderer handles by browsing fixtures.
• Cross-pipeline validation — the same fixture can be consumed by unit tests, golden tests, reftests, probe tests, and visual inspection.

What should be covered

A fixture should exist for every rendering behavior, format variant, or edge case that the engine supports or intends to support. This includes:

• Each CSS property / SVG element the htmlcss or SVG renderer handles
• Format I/O round-trips (SVG → Grida, .grida decode)
• Edge cases: zero-size, empty content, deeply nested, degenerate inputs
• Unsupported-but-tracked features (the fixture documents the gap)

Best practices

• One concept per file. Don't combine unrelated properties.
• Self-contained. No external resources, network fetches, or scripts.
• Minimal. Only enough structure to isolate the behavior under test.