‹ 首页

fixtures

@gridaco · 收录于 今天 · 上游提交 今天

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

适合你,如果你经常编写测试并需要管理测试数据

/ 通过 npx 安装 校验哈希
npx oh-my-skill add gridaco/grida/fixtures
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- gridaco/grida/fixtures
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify gridaco/grida/fixtures
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
2558GitHub stars
~1.1K上下文体积 · 单文件
索引托管

怎么用

技能原文 SKILL.md作者撰写 · Apache-2.0 · 2c73d55

Fixtures

What fixtures are

Fixtures are static input files — HTML, SVG, CSS, JSON, .grida, .fig, 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 codebase supports or intends to support. This includes:

  • Each CSS property / SVG element the htmlcss or SVG renderer handles
  • Format I/O round-trips (Figma → Grida, SVG → Grida, clipboard paste)
  • 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.
  • Probe-friendly. High-contrast palette (prefer B/W), round pixel values, ≤ 3 colors. Designed for headless pixel probing, not human aesthetics.
  • Descriptive naming. <domain>-<property>[-<descriptor>].<ext> — the filename alone should tell you what's being tested.
  • Labeled specimens. Within a fixture, label each test case with the value being exercised so both humans and heuristics can identify regions. Keep labels short, and pin the dimensions of any container holding a label (flex item, grid cell, stretched block) so font-advance-width differences between engines can't leak into box geometry. When a test pipeline offers a text-neutralizing stylesheet (e.g. fixtures/test-html/_reftest/hide-text.css for the htmlcss reftests), prefer that over stripping the label — keeping the text helps the next reader understand the fixture.
  • Match the fixture's subject to the viewport policy. For refbrowser fixtures under fixtures/test-html/, paint / visual-property fixtures should size their root to a preset viewport (via min-height) so grida's cull and Chromium's screenshot have identical dimensions. Layout fixtures (box-model, flex, grid, intrinsic sizing) must NOT force a body size — the output dimensions _are_ what the test measures; a min-height hack contaminates the result. See [fixtures/test-html/README.md](../../../fixtures/test-html/README.md) for the preset list, the paint-vs-layout rule, and the per-fixture viewport workflow for layout tests.
  • Don't duplicate. Before adding a fixture, check if an existing one already covers the behavior. Extend or split rather than duplicate.
Git inclusion policy
Checked in (fixtures/)

All directories under fixtures/ except fixtures/local/ are committed to the repository. These are small, purpose-built files that are part of the test suite.

fixtures/
├── css/              # CSS stylesheets
├── fonts/            # Bundled font binaries (deterministic text tests)
├── images/           # Test images
├── test-fig/         # Figma clipboard / REST fixtures
├── test-figma/       # Figma archive fixtures
├── test-grida/       # .grida format fixtures
├── test-html/        # HTML+CSS renderer fixtures (L0, etc.)
├── test-markdown/    # Markdown fixtures
├── test-svg/         # SVG fixtures
├── text/             # Plain text samples
└── local/            # ← gitignored, see below
Not checked in (fixtures/local/)

fixtures/local/ is gitignored. It holds large, third-party, or benchmark-only datasets that are meaningful for local development but too large or license-restricted for the repository:

  • W3C_SVG_11_TestSuite — W3C SVG 1.1 conformance suite (~50 MB)
  • resvg-test-suite — resvg's feature-focused SVG tests
  • oxygen-icons-5.116.0 — icon set for stress testing
  • perf — large scenes for benchmarking

These must be downloaded separately by developers who need them.

Referencing local-only fixtures

Never reference fixtures/local/ paths in committed code, tests, or documentation. Local fixtures do not exist in CI or on other developers' machines. Specifically:

  • Do not include!(), read_to_string(), or fs::read() a local/ path in any Rust test or example that runs in CI.
  • Do not hardcode fixtures/local/ paths in docs, READMEs, or AGENTS files as if they are always available.
  • If a doc needs to mention a local suite (e.g. for reftest instructions), clearly mark it as local-only and note that the developer must download it first.
  • Tests that depend on local fixtures must be gated (e.g. #[ignore] with a comment, or behind a feature flag) so they don't fail in CI.
按 Apache-2.0 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。