Token导航 LogoToken导航

Agent Skill · 研究检索

rust-write-tests(Rust write tests 搜索)

用于辅助测试设计、自动化测试、用例整理和回归验证。它适合让 Agent 编写单元测试、端到端测试、测试计划或根据失败日志定位问题。使用时需要确认项目测试框架、运行命令和夹具数据,避免为了通过测试而改坏真实逻辑;涉及浏览器或外部服务时,应区分本地模拟、测试环境和生产环境。

rust-write-tests 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为执行命令;许可证信息还不明确,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 35,882。

总安装 2,012周安装 83GitHub Stars 131下载 657核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:rust-write-tests(Rust write tests 搜索)
来源仓库:https://github.com/pproenca/dot-skills
仓库路径:skills/rust-write-tests
安装命令:
npx skills add https://github.com/pproenca/dot-skills --skill rust-write-tests
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/pproenca/dot-skills --skill rust-write-tests

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

rust-write-tests 用于辅助测试设计、自动化测试和回归验证,适合编写单元测试或分析失败日志。适用于 Rust 项目中的测试场景,需确认项目测试框架和运行命令。通过 npx skills add 命令从指定 GitHub 仓库安装,需结合夹具数据和本地环境使用。

涉及浏览器或外部服务时应区分测试环境与生产环境,避免误改真实逻辑。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/rust-write-tests

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/pproenca/dot-skills --skill rust-write-tests;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要执行命令,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

rust-write-tests 怎么安装?

在终端执行 npx skills add https://github.com/pproenca/dot-skills --skill rust-write-tests。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

rust-write-tests 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

rust-write-tests 需要什么权限?

权限级别是执行命令。安装流程涉及命令执行,可能通过 npx skills add https://github.com/pproenca/dot-skills --skill rust-write-tests 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

rust-write-tests 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

rust-write-tests 用的人多吗?

公开数据是累计安装 2,012 次,近一周安装 83 次,下载 657 次,GitHub 131 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

rust-write-tests 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 需要执行命令,装到常用环境前要先评估影响面。
  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 不能接受 Skill 在你机器上执行命令的人。
  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
rust-write-tests

Rust write tests 搜索 · 本页

2,012131执行命令未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Rust Test Writing Skill

Write tests that catch real bugs. Every test must guard a specific invariant -- not just prove the code "works."

The "What Could Break?" Framework

Before writing any test, answer these four questions:

  1. What invariant does this code maintain? (e.g., "deserialized config always has a default profile")
  2. What edge case would violate it? (e.g., "empty TOML table, missing key, extra unknown key")
  3. What platform difference could surface? (e.g., "path separators, case sensitivity, symlink behavior")
  4. What would a future refactor accidentally break? (e.g., "field added to struct but not to Display impl")

If you can only answer #1, your test is a happy-path test. Answer all four and you have a regression suite.

The 5 Test Transformations

Each transformation shows a superficial test pattern and its expert replacement.

Transformation 1: Weak assertions -> whole-object comparison

// BEFORE: proves nothing about the rest of the struct
let result = parse_config(input)?;
assert!(result.is_ok());

// AFTER: catches any unexpected field change
use pretty_assertions::assert_eq;
let result = parse_config(input)?;
assert_eq!(result, Config {
    name: "default".into(),
    timeout: Duration::from_secs(30),
    retries: 3,
    verbose: false,
});

Transformation 2: Single happy-path -> targeted test suite

// BEFORE: one test, one path
#[test]
fn test_parse_config() {
    let cfg = parse("valid input").unwrap();
    assert!(cfg.is_valid());
}

// AFTER: 3-6 tests covering happy, error, edge, platform
#[test]
fn parse_config_returns_defaults_for_minimal_input() { .. }
#[test]
fn parse_config_rejects_negative_timeout() { .. }
#[test]
fn parse_config_preserves_unknown_fields_as_extensions() { .. }
#[test]
fn parse_config_handles_empty_string_gracefully() { .. }
#[cfg(windows)]
#[test]
fn parse_config_normalizes_backslash_paths() { .. }

Transformation 3: Inline test module -> sibling _tests.rs file

// BEFORE: tests pollute the production file diff
// foo.rs
pub fn compute() -> u32 { 42 }
#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn it_works() { assert_eq!(compute(), 42); }
}

// AFTER: production code and test code in sibling files
// foo.rs
pub fn compute() -> u32 { 42 }
#[cfg(test)]
#[path = "foo_tests.rs"]
mod tests;

// foo_tests.rs
use super::*;
#[test]
fn compute_returns_expected_value() { assert_eq!(compute(), 42); }

For mod.rs modules, use mod_tests.rs.

Transformation 4: String-based test data -> typed struct construction

// BEFORE: silent breakage when fields change
let input: Config = serde_json::from_str(r#"{"name":"test","timeout":30}"#)?;

// AFTER: compile-time safety for field additions/renames
fn make_config(name: &str, timeout_secs: u64) -> Config {
    Config {
        name: name.to_string(),
        timeout: Duration::from_secs(timeout_secs),
        retries: 0,
        verbose: false,
    }
}
let input = make_config("test", 30);

Factory functions for domain objects let each test construct exactly the fixture it needs. No shared mutable state. No JSON parsing at test time.

Transformation 5: HashMap in fixtures -> BTreeMap for determinism

// BEFORE: test passes 99% of the time, flakes in CI
let mut map = HashMap::new();
map.insert("b", 2);
map.insert("a", 1);
assert_eq!(format!("{map:?}"), r#"{"a": 1, "b": 2}"#); // order not guaranteed

// AFTER: deterministic iteration order
let mut map = BTreeMap::new();
map.insert("b", 2);
map.insert("a", 1);
assert_eq!(format!("{map:?}"), r#"{"a": 1, "b": 2}"#); // always this order

Use BTreeMap whenever output order affects assertions or snapshots.

Test Flake Hunting Protocol

Bolin's single most frequent pattern (97+ references across 30+ commits). When a test is flaky, follow this exact protocol:

  1. Identify the race window -- read the event-emission code, find where timing assumptions break. Locate the exact line where the test assumes an event has arrived or a state has changed without proof.
  2. Replace timing with event-driven sync -- wait for a specific event instead of sleeping or assuming order. Never use sleep as a synchronization primitive.
  3. Make assertions order-independent -- sort collected values, use sets, or match by content not position. Non-deterministic event ordering is not a bug; asserting on it is.
  4. Stress-test the fix -- run with the exact command: cargo nextest run -p <crate> -j 2 --no-fail-fast --stress-count 50 --status-level leak
  5. Document the non-determinism in the commit message -- explain why the timing assumption was wrong and what synchronization replaced it.
// BEFORE (timing-dependent):
tokio::time::sleep(Duration::from_millis(100)).await;
assert_eq!(events.len(), 2);
assert_eq!(events[0].type_name, "item.create");
assert_eq!(events[1].type_name, "audio.delta");

// AFTER (event-driven, order-independent):
wait_for_event(&rx, |e| e.type_name == "item.create").await;
wait_for_event(&rx, |e| e.type_name == "audio.delta").await;
// OR: collect, sort, compare
let mut types: Vec<_> = events.iter().map(|e| &e.type_name).collect();
types.sort();
assert_eq!(types, vec!["audio.delta", "item.create"]);

Common flake sources to watch for:

  • turn/started emitted optimistically before state is actually ready
  • Event ordering across async channels (mpsc, broadcast)
  • HashMap iteration order in serialized output
  • Test harness Drop racing with child process shutdown (close stdin first, then wait, then kill)

Intent-Based Assertions

Replace exact command-string matching with intent-based semantic matching. Check that the test observes the right INTENT (operation + target) rather than a specific command format that varies across platforms or refactors.

// BEFORE: brittle -- breaks if command formatting changes
assert_eq!(cmd.to_string(), "rm -rf /tmp/workspace/build");

// AFTER: intent-based -- asserts the operation and target
assert_eq!(cmd.operation(), Operation::Remove);
assert!(cmd.target().ends_with("workspace/build"));
assert!(cmd.is_recursive());

When exact strings are unavoidable, assert on the semantically meaningful parts (path suffix, flag presence) rather than the full formatted string.

Test Naming Convention

Pattern: {subject}_{scenario}_{expected_outcome}

A failed test name must be an actionable bug description. When it fails in CI, the name alone tells you what broke. The name should read as a specification: if it fails, you know exactly what invariant was violated.

Exemplary names:

sandbox_detection_requires_keywords
sandbox_detection_ignores_non_sandbox_mode
aggregate_output_rebalances_when_stderr_is_small
parse_config_rejects_negative_timeout
permissions_profiles_reject_writes_outside_workspace_root
permissions_profiles_allow_network_enablement
legacy_sandbox_mode_config_builds_split_policies_without_drift
under_development_features_are_disabled_by_default
usage_limit_reached_error_formats_free_plan
unexpected_status_cloudflare_html_is_simplified
root_write_plus_carveouts_still_requires_platform_sandbox
explicit_unreadable_paths_prevent_auto_approval_for_external_sandbox
denied_hosts_take_priority_over_allowed_hosts_glob

Anti-pattern names: test_parse, it_works, test_config_1, happy_path.

Testing Stack Quick Reference

ScenarioTool
HTTP mockingwiremock::MockServer
Filesystem isolationTempDir (tempfile crate)
Async tests#[tokio::test]
UI / output snapshotsinsta::assert_snapshot!
Struct comparisonpretty_assertions::assert_eq
Enum variant checksassert_matches!
Deterministic collectionsBTreeMap over HashMap
Flake stress-testingcargo nextest run --stress-count 50

When to use each

  • wiremock: Any test that would hit a real HTTP endpoint. Mount responses with Mock::given().respond_with(). Assert request bodies after the test.
  • TempDir: Every test that touches disk. Never mutate the process environment. Never hardcode /tmp or C:\.
  • insta: TUI widgets, CLI output, error messages -- anything where the exact text matters. Render to a buffer, snapshot with assert_snapshot!.
  • pretty_assertions: Default for all assert_eq! calls. Gives colored diffs on failure. Import at the top of every test file.
  • nextest stress: After fixing any flaky test. Always run with -j 2 --no-fail-fast --stress-count 50 to confirm the fix holds under concurrency.

Self-Review Checklist

After writing tests, verify every item. Fix every violation before presenting the tests.

[ ] Uses pretty_assertions::assert_eq (not std assert_eq)
[ ] Compares entire objects, not individual fields
[ ] Each test guards a specific invariant (not just "it works")
[ ] Test names follow {subject}_{scenario}_{expected_outcome}
[ ] Test names encode the invariant being guarded
[ ] TempDir for any filesystem tests (no hardcoded paths)
[ ] No process environment mutation (no std::env::set_var)
[ ] Error paths tested (not just happy path)
[ ] At least 3 tests for any non-trivial function
[ ] BTreeMap used where iteration order affects assertions
[ ] Test file is a sibling _tests.rs, not inline mod tests {}
[ ] No timing-dependent assertions (no sleep -> assert)
[ ] Order-independent where event order is non-deterministic
[ ] String assertions use intent matching, not exact format

平台分布

Codex

38.57%
按下载量换算253

Claude

28.57%
按下载量换算188

Cursor

18.73%
按下载量换算123

Gemini CLI

9.91%
按下载量换算65

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

执行命令

安装流程涉及命令执行,可能通过 npx skills add https://github.com/pproenca/dot-skills --skill rust-write-tests 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills