writing-rust-tests

A set of rules for writing and running Rust tests in a Cargo workspace, which is a project containing multiple related Rust packages.

In plain words
What is it for?
Use it when adding unit or integration tests, expanding test cases, checking command-line programs, using temporary files, or running the Rust test suite.
Why use it?
It keeps tests consistent by requiring the project’s preferred test framework, shared test cases, property testing where appropriate, and repository-specific checks.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/harmont-dev/harmont-cli/writing-rust-tests
Any agent
npx skills add harmont-dev/harmont-cli --skill writing-rust-tests
Clone the repo
git clone --depth 1 https://github.com/harmont-dev/harmont-cli

Made for: Claude Code, Codex.

Per session 84 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,822 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00084 $0.01822
Opus 5 $0.00042 $0.00911
Sonnet 5 $0.00017 $0.00364
Haiku 4.5 $0.00008 $0.00182

Measured yesterday against content hash 498a8ffbc50e, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

writing-rust-tests scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.claude/skills/writing-rust-tests/SKILL.md · 151 lines

How it starts

The opening of the file, as written. The whole thing — 151 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Writing Rust Tests

Overview

This is a Cargo workspace (edition 2024). Tests here follow three non-negotiable defaults:

  1. #[rstest], not bare #[test]. Every test function is annotated #[rstest], even when it takes no cases yet. This keeps the whole suite uniform and lets any test grow cases without a rewrite.
  2. Parametrize with #[case], never duplicate. Two or more test functions that differ only in input/expected values ARE ONE parametrized test. A hand-rolled for loop over inputs IS a parametrized test written wrong.
  3. Reach for proptest when the property holds over a whole domain, not just the few points you picked.

Violating the letter of these rules is violating the spirit. "It's only two cases" and "a loop is basically the same" are how the suite rots into scattered, unreadable #[test] functions.

When to Use

  • Adding a new function/type and covering it with tests.
  • Adding cases to existing tests, or a new crates/<crate>/tests/*.rs integration test.
  • The user says "write tests", "add coverage", "test this", or "run the tests".
  • You are about to write #[test], a for loop inside a test, or the second near-identical test function.

The Decision

digraph t {
    "What am I testing?" [shape=diamond];
    "Same logic, different inputs?" [shape=diamond];
    "Property true over a whole domain?" [shape=diamond];
    "rstest + #[case] per input" [shape=box];
    "proptest! block" [shape=box];
    "single #[rstest] fn" [shape=box];

    "What am I testing?" -> "Same logic, different inputs?";
    "Same logic, different inputs?" -> "rstest + #[case] per input" [label="yes"];
    "Same logic, different inputs?" -> "Property true over a whole domain?" [label="no"];
    "Property true over a whole domain?" -> "proptest! block" [label="yes"];
    "Property true over a whole domain?" -> "single #[rstest] fn" [label="no"];
}

rstest and proptest are already workspace dev-deps (see crates/hm-common). If a crate needs them, add to its [dev-dependencies].

Read the full file on GitHub · 151 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 151 lines · 84 tokens per session scan A 498a8ffbc50e

Subscribe to this mod's changes

writing-rust-tests is a skill published in the GitHub repository harmont-dev/harmont-cli (21 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 84 tokens to every session and 1,822 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

zuke-write-build

Write or edit a Zuke build (zuke.ts) — the code-first, strongly-typed build system for Deno/TypeScript. Use when adding or changing targets, wiring dependencies, calling a tool wrapper (DenoTasks, NpmTasks, DockerTasks, ...), generating CI, or authoring/refactoring a zuke.ts build file. For first-time project…

zuke-build/zuke · 93 tokens

zuke-setup

Set up Zuke — a code-first, strongly-typed build automation system for Deno/TypeScript — in a project. Use when the user wants to add Zuke to a repo, scaffold a zuke.ts build file, install the Zuke CLI, or bootstrap the ./zuke launcher. After scaffolding, switch to the zuke-write-build skill to author targets.

zuke-build/zuke · 82 tokens

ci-secure

Scans a repo's GitHub Actions workflows for the ten critical CI/CD attack vectors — template injection, fork code executed with privileges (pwn requests), cache poisoning, impostor action SHAs, secrets dumps, GITHUBENV hijack, write-token untrusted triggers, credentials in caches/artifacts, unverified remote code…

starslingdev/skills · 230 tokens

skills-registry-security

Checks the third-party security audit status of a skill published to a skills registry (skills.sh) across every cached surface, decides whether a failing finding is real or points at content already removed, and drives a stale badge to green unattended. Runs a real install to capture what users see, reads the…

starslingdev/skills · 214 tokens

sling

Diagnoses GitHub Actions failures and attributes CI time and cost using StarSling's sling CLI. Invoke this BEFORE using gh or fetching any logs whenever the user asks why a job or run failed, what made a run slow, about runner minutes or CI cost, asks to re-run or cancel a run, or pastes a GitHub Actions URL — sling…

starslingdev/skills · 139 tokens

ci-score

Grades a repository's GitHub Actions configuration against CI best practices (the CI Score: eleven pass/fail configuration facts computed from the repo's own workflow YAML) and hands back concrete fixes for every gap, ranked by impact and risk, each with an apply-now option and a paste-able agent prompt. Use when: (1)…

starslingdev/skills · 209 tokens