![Rust 测试代码分析实战指南：基于 dotnet-skills 多语言测试分析扩展的 `[test]` 与 `cargo test` 参考手册](http://pic.xiahunao.cn/yaotu/Rust 测试代码分析实战指南：基于 dotnet-skills 多语言测试分析扩展的 `[test]` 与 `cargo test` 参考手册)
Rust 测试代码分析实战指南基于 dotnet-skills 多语言测试分析扩展的#[test]与cargo test参考手册【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills导读本文围绕当前仓库中 Rust 测试框架参考文件系统讲解如何面向 Rust 测试代码开展多语言测试分析从测试发现、断言检测、睡眠/延迟识别、跳过/忽略注解到 Mystery Guest 外部依赖识别、集成测试标记、Setup/Teardown 模式以及标签Tag支持能力。该参考数据由test-analysis-extensions技能统一供给assertion-quality、test-anti-patterns、test-gap-analysis、test-smell-detection、test-tagging等 polyglot 测试分析技能使用见 SKILL.md。读完本文你将掌握 Rust 内置测试框架的完整分析要素、各能力维度的强弱定位、常见反模式的判定口径以及如何在报告类分析中正确输出而非误改源码。参考文件的定位与使用方式rust.md是test-analysis-extensions技能提供的按语言拆分参考文件之一与dotnet.md、python.md、typescript.md、java.md、go.md、ruby.md、swift.md、kotlin.md、powershell.md、cpp.md并列存放于 extensions 目录。其典型调用链路为分析技能先检测目标代码库的主导语言与测试框架通过test-analysis-extensions技能获取可用扩展文件清单读取与语言匹配的扩展文件后再执行分析见 SKILL.md 中的 Usage 章节若一个项目中混用多种测试框架例如同时存在 Jest 与 Mocha应读取所有相关扩展文件各扩展文件使用相同的分析维度组织内容从而让上层分析技能保持语言无关。值得注意的设计约束同样记录于 SKILL.md扩展文件是数据而非执行指南——它们告诉技能“每种语言如何检测”而不是“对发现结果应该怎么想”。当语言检测不确定时优先读取多个扩展文件而不是猜测。Capability tagsRust 测试分析的能力定位每个扩展文件都声明逐能力支持程度使上层技能可以安全地门控行为。Rust 的定位如下CapabilitySupportTest discoveryStrong —#[test]/#[tokio::test]/#[cfg(test)] mod tests/tests/集成测试目录Assertion detectionStrong —assert!、assert_eq!、assert_ne!、?Result 返回型测试Sleep/delay detectionStrong —thread::sleep、tokio::time::sleepSkip/ignore detectionStrong —#[ignore]、#[cfg(...)]门控Setup/teardown detectionModerate — 无内建 fixture依赖构造函数与Drop或外部 crateTag supportreport-only / convention-based— 无规范属性部分 craterstest、nextest支持按名称过滤测试这一定位与上层技能的处理策略直接对应。例如test-tagging技能见 SKILL.md将框架划分为三类能力auto-edit存在规范属性、可安全写入源码、report-only无公认规范属性只输出审计报告、convention-based仅通过命名/注释约定体现标签。Rust 属于后者组合默认只报告不修改源码只有当项目已经遵循某一明确约定时才切换到auto-edit模式写入约定式标签。Test File IdentificationRust 测试文件的识别约定ConventionDescription#[test]标准测试属性#[cfg(test)] mod tests { ... }与源码同文件共置的单元测试tests/*.rs集成测试每个文件是一个独立 crate#[tokio::test]/#[async_std::test]异步测试需要异步运行时 crate#[rstest]通过rstestcrate 实现的参数化测试#[should_panic]期望 panic 的测试Doc tests///注释中包含可执行代码块#[bench]nightly/criterionbenchmarks基准测试识别要点单元测试与源码共置在mod tests中而tests/目录下每个文件独立编译为单独的 crate这一模型与其他语言差异明显异步测试依赖tokio/async-std运行时属性分析时必须留意缺失运行时属性的async fn测试详见后文校准说明。Assertion APIsRust 断言 API 全景CategoryBuilt-inproptest / quickcheckEqualityassert_eq!(actual, expected)手写prop_assert_eq!Inequalityassert_ne!(actual, expected)prop_assert_ne!Booleanassert!(condition, msg)prop_assert!(...)Pattern matchassert!(matches!(value, Pattern))n/aPanic#[should_panic]/#[should_panic(expected msg)]n/aErrorresult.unwrap()出错时 panic/?传播n/aFailpanic!(reason)/unreachable!()n/a第三方断言库pretty_assertions带彩色 diff 的assert_eq!、assert_matches、claim提供assert_ok!、assert_err!。Result 返回型测试Rust 2018Rust 2018 起测试函数可以返回Result?运算符让错误传播更优雅#[test] fn parses_valid_input() - Result(), Boxdyn std::error::Error { let v parse(1)?; assert_eq!(v, 1); Ok(()) }Result(), Boxdyn Error是其中最通用的签名也可以用anyhow::Result()等具体错误类型见下文异常处理示例。这种写法直接对应断言检测能力中?的识别?传播本身即构成错误路径断言。Sleep/Delay Patterns睡眠与延迟模式PatternExampleSync sleepstd::thread::sleep(Duration::from_secs(1))Async sleep (tokio)tokio::time::sleep(Duration::from_secs(1)).awaitasync-std sleepasync_std::task::sleep(Duration::from_secs(1)).awaitSpin waitwhile !cond() { std::thread::sleep(...) }Acceptable (tokio time control)tokio::time::pause()tokio::time::advance(...)这是test-smell-detection中Sleepy Test固定墙钟睡眠等待结果的判定依据。文档明确提示thread::sleep属于 Sleepy Test 信号异步场景优先推荐tokio::time::pause()配合advance(...)虚拟时间推进同步场景则改为带超时的显式轮询polling——这正是test-smell-detection的 High-Signal 决策表中“Await or poll the condition with a timeout”建议的落地形式见 SKILL.md。Skip/Ignore Annotations跳过与忽略机制MechanismExample#[ignore]默认被排除用cargo test -- --ignored运行#[ignore reason]带原因Rust 1.55#[cfg(feature x)]除非启用 feature 否则跳过#[cfg(target_os linux)]在其他 OS 上跳过#[cfg(not(miri))]在 Miri 解释器下跳过Conditional skip手动if !cfg!(...) { return; }反模式两点实践要点第一#[ignore]未附带原因本身就是一种坏味道应按 Ignored Test 低严重度标记第二#[cfg(...)]门控既是跳过机制也是集成测试的标记手段如#[cfg(feature integration-tests)]分析时要注意二者的重叠语义。Exception HandlingRust 异常处理的惯用替代Rust 没有传统异常测试中的“异常处理”通过三种惯用方式表达// should_panic with specific message: #[test] #[should_panic(expected must be positive)] fn parses_negative_panics() { parse_amount(-5); } // Result return ?: #[test] fn places_order_ok() - anyhow::Result() { let order service.place_order(valid_order())?; assert_eq!(order.id, 42); Ok(()) } // Match on Err for specific variant: let err service.place_order(empty).unwrap_err(); assert!(matches!(err, OrderError::Empty));参考文档特别警告一个典型坏味道测试仅对生产代码返回的Result调用.unwrap()却不断言错误变体——这会把“意外错误”与“测试失败”混为一谈掩盖真正的错误来源。#[should_panic(expected ...)]用于限定 panic 消息而不带expected的#[should_panic]会在任意 panic 时通过过于宽泛属于坏味道。这也是test-anti-patterns技能见 SKILL.md异常处理Exception Handling类诊断的重要素材。Mystery GuestRust 常见外部依赖耦合模式Mystery Guest 指测试隐式依赖未声明的文件、网络服务、环境变量或数据库。Rust 中常见信号IndicatorWhat to look forFile systemstd::fs::read、std::fs::write、硬编码路径Database针对真实数据库的sqlx::PgPool::connect、rusqlite::Connection::open(path)Network访问真实 URL 的reqwest::get、hyperclient、裸TcpStream::connectEnvironmentstd::env::var(X).unwrap()Acceptabletempfile::TempDir、httpmock、wiremock-rs、mockito、针对内存 SQLite 的sqlxtest pool、start_paused true的tokio::test判定口径来自test-smell-detection的校准规则集成测试标记可以合法化已声明的真实外部资源但不能合法化固定睡眠或无断言的执行本地临时文件依然满足正式的 Mystery Guest 定义封闭式创建与清理如tempfile::TempDir只能降低严重度不改变其分类。Integration Test Markers集成测试标记tests/顶层目录包含集成测试测试名包含_integration_、_e2e_、_acceptance_Feature flags#[cfg(feature integration-tests)]使用testcontainers等 crate 隐含集成性质cargo nextest的 profile 名称[profile.integration]Setup/TeardownRust 的无 fixture 生态Rust 没有原生 fixture 框架常见模式PatternDescriptionHelper functionfn setup() - Foo { ... }在每个测试开头调用Dropimplementation测试本地守卫结构体上的副作用清理rstestfixtures#[fixture] fn db() - Db { ... }#[rstest] fn t(db: Db) { ... }test-contextcrate提供每测试setup/teardowntraitserial_testcrate用#[serial]避免并行测试干扰once_cell/lazy_static惰性全局初始化慎用——跨测试共享状态这就是 Capability 表中 Setup/teardown 标记为Moderate的原因没有统一的生命周期钩子语法检测需要识别多种惯用法。Drop作为 RAII 清理手段是 Rust 区别于其他语言的最大特色而once_cell/lazy_static的全局共享状态是并行cargo test下的经典竞态来源对应校准说明中“需要#[serial]否则并行执行易 flaky”的条目。Tag/Trait Attributes为test-tagging提供的标签策略默认模式report-only / convention-based。Rust 没有规范的按测试标签属性可行策略模块分组mod positive { ... }、mod boundary { ... }— 配合cargo test boundary::过滤测试名前缀fn test_negative_invalid_input_returns_error()— 可通过cargo test negative_过滤集成/E2E 的 feature flags#[cfg(feature e2e)]cargo nextest通过nextest.toml的过滤表达式支持测试分组只有当项目已经遵循某一约定时才切换到auto-edit模式。这与test-tagging技能的能力分类表一致Rust无项目专属 cfg 约定时被归为report-only分析输出一张“测试 → 建议标签”的 Markdown 映射表即可不得修改源码若项目存在#[cfg(feature ...)]等已确认的约定才按convention-based处理并需用户确认后写入。test-tagging的 Validation 清单也明确要求report-only框架不得修改任何源文件。Language-specific calibration notes语言级校准要点参考文档末尾给出了针对 Rust 的校准说明这是避免误报的关键Doc tests 是真实测试—cargo test会运行它们。若用户将 lib 的 doc 注释纳入范围应视其为测试。不带expected ...的#[should_panic]在任意 panic 时都通过 — 过于宽泛是坏味道。测试中的.unwrap()/.expect()对类型正确的解包可以接受但会掩盖错误来源在Result返回型测试中优先推荐?。属性化测试proptest!、quickcheck!生成输入用例应视为参数化测试而非重复测试。#[ignore]不带原因是坏味道 — 标记为低严重度 Ignored Test。需要#[tokio::test]却缺失的异步测试会静默永不运行— 任何缺少运行时属性的async fn测试都必须标记。测试中的thread::sleep是 Sleepy Test — 异步优先tokio::time::pause()同步用显式轮询。修改static mut或全局Mutex...状态的测试需要#[serial]来自serial_test— 否则并行cargo test下会 flaky。带#![deny(warnings)]交叉编译的#[cfg(test)]模块有时会构建失败 — 可记录但不标记为坏味道。裸assert!(x)无消息在适合assert_eq!的位置是可接受的 — 不要强制要求消息。实战串联一次完整的 Rust 测试审计流程综合以上要素一次基于该参考数据的 Rust 测试分析可以按如下流程执行对应各上层技能的约定工作流识别语言与框架通过test-analysis-extensions定位到 rust.md确认目标代码库使用内置#[test]cargo test。测试发现按 Test File Identification 表扫描#[test]、#[cfg(test)] mod tests、tests/*.rs、#[tokio::test]、doc tests建立测试清单。断言与异常检测按 Assertion APIs 表识别assert_eq!/assert_ne!/matches!/?/#[should_panic]对仅.unwrap()不验错误变体的测试打标记。睡眠与跳过识别捕获thread::sleep/tokio::time::sleepSleepy Test 信号区分#[ignore]带/不带原因与#[cfg(...)]门控。外部依赖识别按 Mystery Guest 表区分文件/数据库/网络/环境变量耦合与可接受的tempfile、httpmock、内存 SQLite 等封闭手段。标签与集成判定识别tests/目录、_integration_/_e2e_命名、#[cfg(feature ...)]标记对于test-tagging因 Rust 默认report-only输出标签映射报告而非修改源码。整套分析由仓库中 test-smell-detection、test-anti-patterns、test-tagging、assertion-quality、test-gap-analysis 等多个 polyglot 技能共同消费而rust.md为其中的 Rust 分支提供统一、可复用的检测口径。结语rust.md的价值在于把 Rust 测试生态的“无 fixture、无规范标签、cfg门控丰富、异步运行时耦合”等特性压缩成一组与语言无关的分析维度表使同一套 polyglot 分析技能在 Rust 上也能给出准确、低误报的结论。理解其 Capability tags 的强弱分级、识别约定与校准要点是正确使用这些测试分析技能的前提——尤其要记住Rust 的标签能力默认是 report-only分析产出报告而不是改写源码。【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Rust 测试代码分析实战指南：基于 dotnet-skills 多语言测试分析扩展的 `[test]` 与 `cargo test` 参考手册
Rust 测试代码分析实战指南基于 dotnet-skills 多语言测试分析扩展的#[test]与cargo test参考手册【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills导读本文围绕当前仓库中 Rust 测试框架参考文件系统讲解如何面向 Rust 测试代码开展多语言测试分析从测试发现、断言检测、睡眠/延迟识别、跳过/忽略注解到 Mystery Guest 外部依赖识别、集成测试标记、Setup/Teardown 模式以及标签Tag支持能力。该参考数据由test-analysis-extensions技能统一供给assertion-quality、test-anti-patterns、test-gap-analysis、test-smell-detection、test-tagging等 polyglot 测试分析技能使用见 SKILL.md。读完本文你将掌握 Rust 内置测试框架的完整分析要素、各能力维度的强弱定位、常见反模式的判定口径以及如何在报告类分析中正确输出而非误改源码。参考文件的定位与使用方式rust.md是test-analysis-extensions技能提供的按语言拆分参考文件之一与dotnet.md、python.md、typescript.md、java.md、go.md、ruby.md、swift.md、kotlin.md、powershell.md、cpp.md并列存放于 extensions 目录。其典型调用链路为分析技能先检测目标代码库的主导语言与测试框架通过test-analysis-extensions技能获取可用扩展文件清单读取与语言匹配的扩展文件后再执行分析见 SKILL.md 中的 Usage 章节若一个项目中混用多种测试框架例如同时存在 Jest 与 Mocha应读取所有相关扩展文件各扩展文件使用相同的分析维度组织内容从而让上层分析技能保持语言无关。值得注意的设计约束同样记录于 SKILL.md扩展文件是数据而非执行指南——它们告诉技能“每种语言如何检测”而不是“对发现结果应该怎么想”。当语言检测不确定时优先读取多个扩展文件而不是猜测。Capability tagsRust 测试分析的能力定位每个扩展文件都声明逐能力支持程度使上层技能可以安全地门控行为。Rust 的定位如下CapabilitySupportTest discoveryStrong —#[test]/#[tokio::test]/#[cfg(test)] mod tests/tests/集成测试目录Assertion detectionStrong —assert!、assert_eq!、assert_ne!、?Result 返回型测试Sleep/delay detectionStrong —thread::sleep、tokio::time::sleepSkip/ignore detectionStrong —#[ignore]、#[cfg(...)]门控Setup/teardown detectionModerate — 无内建 fixture依赖构造函数与Drop或外部 crateTag supportreport-only / convention-based— 无规范属性部分 craterstest、nextest支持按名称过滤测试这一定位与上层技能的处理策略直接对应。例如test-tagging技能见 SKILL.md将框架划分为三类能力auto-edit存在规范属性、可安全写入源码、report-only无公认规范属性只输出审计报告、convention-based仅通过命名/注释约定体现标签。Rust 属于后者组合默认只报告不修改源码只有当项目已经遵循某一明确约定时才切换到auto-edit模式写入约定式标签。Test File IdentificationRust 测试文件的识别约定ConventionDescription#[test]标准测试属性#[cfg(test)] mod tests { ... }与源码同文件共置的单元测试tests/*.rs集成测试每个文件是一个独立 crate#[tokio::test]/#[async_std::test]异步测试需要异步运行时 crate#[rstest]通过rstestcrate 实现的参数化测试#[should_panic]期望 panic 的测试Doc tests///注释中包含可执行代码块#[bench]nightly/criterionbenchmarks基准测试识别要点单元测试与源码共置在mod tests中而tests/目录下每个文件独立编译为单独的 crate这一模型与其他语言差异明显异步测试依赖tokio/async-std运行时属性分析时必须留意缺失运行时属性的async fn测试详见后文校准说明。Assertion APIsRust 断言 API 全景CategoryBuilt-inproptest / quickcheckEqualityassert_eq!(actual, expected)手写prop_assert_eq!Inequalityassert_ne!(actual, expected)prop_assert_ne!Booleanassert!(condition, msg)prop_assert!(...)Pattern matchassert!(matches!(value, Pattern))n/aPanic#[should_panic]/#[should_panic(expected msg)]n/aErrorresult.unwrap()出错时 panic/?传播n/aFailpanic!(reason)/unreachable!()n/a第三方断言库pretty_assertions带彩色 diff 的assert_eq!、assert_matches、claim提供assert_ok!、assert_err!。Result 返回型测试Rust 2018Rust 2018 起测试函数可以返回Result?运算符让错误传播更优雅#[test] fn parses_valid_input() - Result(), Boxdyn std::error::Error { let v parse(1)?; assert_eq!(v, 1); Ok(()) }Result(), Boxdyn Error是其中最通用的签名也可以用anyhow::Result()等具体错误类型见下文异常处理示例。这种写法直接对应断言检测能力中?的识别?传播本身即构成错误路径断言。Sleep/Delay Patterns睡眠与延迟模式PatternExampleSync sleepstd::thread::sleep(Duration::from_secs(1))Async sleep (tokio)tokio::time::sleep(Duration::from_secs(1)).awaitasync-std sleepasync_std::task::sleep(Duration::from_secs(1)).awaitSpin waitwhile !cond() { std::thread::sleep(...) }Acceptable (tokio time control)tokio::time::pause()tokio::time::advance(...)这是test-smell-detection中Sleepy Test固定墙钟睡眠等待结果的判定依据。文档明确提示thread::sleep属于 Sleepy Test 信号异步场景优先推荐tokio::time::pause()配合advance(...)虚拟时间推进同步场景则改为带超时的显式轮询polling——这正是test-smell-detection的 High-Signal 决策表中“Await or poll the condition with a timeout”建议的落地形式见 SKILL.md。Skip/Ignore Annotations跳过与忽略机制MechanismExample#[ignore]默认被排除用cargo test -- --ignored运行#[ignore reason]带原因Rust 1.55#[cfg(feature x)]除非启用 feature 否则跳过#[cfg(target_os linux)]在其他 OS 上跳过#[cfg(not(miri))]在 Miri 解释器下跳过Conditional skip手动if !cfg!(...) { return; }反模式两点实践要点第一#[ignore]未附带原因本身就是一种坏味道应按 Ignored Test 低严重度标记第二#[cfg(...)]门控既是跳过机制也是集成测试的标记手段如#[cfg(feature integration-tests)]分析时要注意二者的重叠语义。Exception HandlingRust 异常处理的惯用替代Rust 没有传统异常测试中的“异常处理”通过三种惯用方式表达// should_panic with specific message: #[test] #[should_panic(expected must be positive)] fn parses_negative_panics() { parse_amount(-5); } // Result return ?: #[test] fn places_order_ok() - anyhow::Result() { let order service.place_order(valid_order())?; assert_eq!(order.id, 42); Ok(()) } // Match on Err for specific variant: let err service.place_order(empty).unwrap_err(); assert!(matches!(err, OrderError::Empty));参考文档特别警告一个典型坏味道测试仅对生产代码返回的Result调用.unwrap()却不断言错误变体——这会把“意外错误”与“测试失败”混为一谈掩盖真正的错误来源。#[should_panic(expected ...)]用于限定 panic 消息而不带expected的#[should_panic]会在任意 panic 时通过过于宽泛属于坏味道。这也是test-anti-patterns技能见 SKILL.md异常处理Exception Handling类诊断的重要素材。Mystery GuestRust 常见外部依赖耦合模式Mystery Guest 指测试隐式依赖未声明的文件、网络服务、环境变量或数据库。Rust 中常见信号IndicatorWhat to look forFile systemstd::fs::read、std::fs::write、硬编码路径Database针对真实数据库的sqlx::PgPool::connect、rusqlite::Connection::open(path)Network访问真实 URL 的reqwest::get、hyperclient、裸TcpStream::connectEnvironmentstd::env::var(X).unwrap()Acceptabletempfile::TempDir、httpmock、wiremock-rs、mockito、针对内存 SQLite 的sqlxtest pool、start_paused true的tokio::test判定口径来自test-smell-detection的校准规则集成测试标记可以合法化已声明的真实外部资源但不能合法化固定睡眠或无断言的执行本地临时文件依然满足正式的 Mystery Guest 定义封闭式创建与清理如tempfile::TempDir只能降低严重度不改变其分类。Integration Test Markers集成测试标记tests/顶层目录包含集成测试测试名包含_integration_、_e2e_、_acceptance_Feature flags#[cfg(feature integration-tests)]使用testcontainers等 crate 隐含集成性质cargo nextest的 profile 名称[profile.integration]Setup/TeardownRust 的无 fixture 生态Rust 没有原生 fixture 框架常见模式PatternDescriptionHelper functionfn setup() - Foo { ... }在每个测试开头调用Dropimplementation测试本地守卫结构体上的副作用清理rstestfixtures#[fixture] fn db() - Db { ... }#[rstest] fn t(db: Db) { ... }test-contextcrate提供每测试setup/teardowntraitserial_testcrate用#[serial]避免并行测试干扰once_cell/lazy_static惰性全局初始化慎用——跨测试共享状态这就是 Capability 表中 Setup/teardown 标记为Moderate的原因没有统一的生命周期钩子语法检测需要识别多种惯用法。Drop作为 RAII 清理手段是 Rust 区别于其他语言的最大特色而once_cell/lazy_static的全局共享状态是并行cargo test下的经典竞态来源对应校准说明中“需要#[serial]否则并行执行易 flaky”的条目。Tag/Trait Attributes为test-tagging提供的标签策略默认模式report-only / convention-based。Rust 没有规范的按测试标签属性可行策略模块分组mod positive { ... }、mod boundary { ... }— 配合cargo test boundary::过滤测试名前缀fn test_negative_invalid_input_returns_error()— 可通过cargo test negative_过滤集成/E2E 的 feature flags#[cfg(feature e2e)]cargo nextest通过nextest.toml的过滤表达式支持测试分组只有当项目已经遵循某一约定时才切换到auto-edit模式。这与test-tagging技能的能力分类表一致Rust无项目专属 cfg 约定时被归为report-only分析输出一张“测试 → 建议标签”的 Markdown 映射表即可不得修改源码若项目存在#[cfg(feature ...)]等已确认的约定才按convention-based处理并需用户确认后写入。test-tagging的 Validation 清单也明确要求report-only框架不得修改任何源文件。Language-specific calibration notes语言级校准要点参考文档末尾给出了针对 Rust 的校准说明这是避免误报的关键Doc tests 是真实测试—cargo test会运行它们。若用户将 lib 的 doc 注释纳入范围应视其为测试。不带expected ...的#[should_panic]在任意 panic 时都通过 — 过于宽泛是坏味道。测试中的.unwrap()/.expect()对类型正确的解包可以接受但会掩盖错误来源在Result返回型测试中优先推荐?。属性化测试proptest!、quickcheck!生成输入用例应视为参数化测试而非重复测试。#[ignore]不带原因是坏味道 — 标记为低严重度 Ignored Test。需要#[tokio::test]却缺失的异步测试会静默永不运行— 任何缺少运行时属性的async fn测试都必须标记。测试中的thread::sleep是 Sleepy Test — 异步优先tokio::time::pause()同步用显式轮询。修改static mut或全局Mutex...状态的测试需要#[serial]来自serial_test— 否则并行cargo test下会 flaky。带#![deny(warnings)]交叉编译的#[cfg(test)]模块有时会构建失败 — 可记录但不标记为坏味道。裸assert!(x)无消息在适合assert_eq!的位置是可接受的 — 不要强制要求消息。实战串联一次完整的 Rust 测试审计流程综合以上要素一次基于该参考数据的 Rust 测试分析可以按如下流程执行对应各上层技能的约定工作流识别语言与框架通过test-analysis-extensions定位到 rust.md确认目标代码库使用内置#[test]cargo test。测试发现按 Test File Identification 表扫描#[test]、#[cfg(test)] mod tests、tests/*.rs、#[tokio::test]、doc tests建立测试清单。断言与异常检测按 Assertion APIs 表识别assert_eq!/assert_ne!/matches!/?/#[should_panic]对仅.unwrap()不验错误变体的测试打标记。睡眠与跳过识别捕获thread::sleep/tokio::time::sleepSleepy Test 信号区分#[ignore]带/不带原因与#[cfg(...)]门控。外部依赖识别按 Mystery Guest 表区分文件/数据库/网络/环境变量耦合与可接受的tempfile、httpmock、内存 SQLite 等封闭手段。标签与集成判定识别tests/目录、_integration_/_e2e_命名、#[cfg(feature ...)]标记对于test-tagging因 Rust 默认report-only输出标签映射报告而非修改源码。整套分析由仓库中 test-smell-detection、test-anti-patterns、test-tagging、assertion-quality、test-gap-analysis 等多个 polyglot 技能共同消费而rust.md为其中的 Rust 分支提供统一、可复用的检测口径。结语rust.md的价值在于把 Rust 测试生态的“无 fixture、无规范标签、cfg门控丰富、异步运行时耦合”等特性压缩成一组与语言无关的分析维度表使同一套 polyglot 分析技能在 Rust 上也能给出准确、低误报的结论。理解其 Capability tags 的强弱分级、识别约定与校准要点是正确使用这些测试分析技能的前提——尤其要记住Rust 的标签能力默认是 report-only分析产出报告而不是改写源码。【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
