‹ 首页

fixtures

@gridaco · 收录于 1 周前 · 上游提交 1 周前

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 缺失或不一致均拒装。
2562GitHub stars
~1.1K上下文体积 · 单文件
索引托管

怎么用

商店整理自技能原文 · 版本 2c73d55 · 表述以原文为准
它做什么

Claude 会指导你编写、组织和管理测试用的静态输入文件(如 HTML、CSS、JSON 等),确保测试可复现且不依赖外部服务。

什么时候触发

当你需要创建新的测试夹具、编写依赖夹具的测试,或决定哪些文件应纳入 Git 版本控制时触发。

装好后可以这样说
Claude 会根据文件类型和用途建议正确的子目录。
Claude 会审查代码,确保没有引用本地专用夹具。
技能原文 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 查看 →

评论

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