ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Rust By Example 测试篇:dev-dependencies 开发依赖详解——为测试、示例与基准测试引入专用依赖

Rust By Example 测试篇:dev-dependencies 开发依赖详解——为测试、示例与基准测试引入专用依赖 文档教程【免费下载链接】rust-by-exampleLearn Rust with examples (Live code editor included)项目地址https://gitcode.com/gh_mirrors/ru/rust-by-example点击查看免费下载本篇技术指南以 Rust By Example 仓库的 测试章节之开发依赖dev-dependencies文档 为核心系统讲解如何在Cargo.toml中为测试、示例examples和基准测试benchmarks声明专用依赖阐明其与普通依赖的本质区别——不会被传播给下游依赖者并给出基于pretty_assertions的完整可运行示例。读完本文你将掌握 dev-dependencies 的声明语法、作用域边界、在单元测试/集成测试/文档测试三种测试风格中的正确用法以及配套的cargo test运行与依赖管理技巧。什么是 dev-dependencies为测试而生的依赖声明在 Rust 项目中大部分依赖是为了支撑程序本身的功能它们被声明在Cargo.toml的[dependencies]部分可参见仓库中的 Cargo 依赖章节。但有时候某些依赖只被测试代码tests、示例代码examples或基准测试代码benchmarks需要并不属于程序运行时的功能组成部分。例如断言增强库如pretty_assertions、assert_cmd用于让测试失败信息更直观随机数据生成库如rand仅用于构造测试数据临时目录管理、HTTP 测试服务器等测试基础设施。如果把这些依赖放进[dependencies]它们会被打包进最终交付的依赖树污染生产依赖、拖慢构建。正确的做法是把它们放进[dev-dependencies]段[dev-dependencies] pretty_assertions 1这是 Rust By Example 仓库 Testing 章节 明确支持的依赖管理方式。该章节指出Rust 的测试体系包含三种风格单元测试Unit testing在模块内用#[cfg(test)]#[test]编写参见 unit_testing.md文档测试Doc testing写在文档注释的代码块中参见 doc_testing.md集成测试Integration testing放在tests/目录通过公共接口调用库参见 integration_testing.md。dev-dependencies 正是为这三种测试场景以及示例、基准测试服务的依赖声明机制。核心特性dev-dependencies 不会被传播这是 dev-dependencies 与普通依赖最本质的区别也是理解其设计意图的关键These dependencies are not propagated to other packages which depend on this package.即这些依赖不会被传播给依赖本包的其他包。这意味着当你开发一个库时测试依赖只存在于你的开发环境中下游用户通过cargo add your-crate或手动添加依赖时不会连带拉取你的 dev-dependenciesdev-dependencies 不参与库的公共编译单元只在你运行测试、构建示例或基准测试时生效。从编译层面理解[dependencies]中的依赖会被链接进你发布的*.rlib/*.so等产物可参考仓库 创建库的章节而 dev-dependencies 只服务于cargo test、cargo run --example、cargo bench这类开发期命令因此不会泄漏到用户侧。这种隔离既保护了下游用户的依赖树整洁也让上游开发者可以放心地在测试中使用任何辅助库。完整实战用 pretty_assertions 升级断言体验原文档给出了一个完整、可复制的示例。首先是Cargo.toml为了聚焦标准的 crate 数据包名、版本、作者等被省略# standard crate data is left out [dev-dependencies] pretty_assertions 1然后是库源码src/lib.rs其中包含一个极简的加法函数以及挂在#[cfg(test)]下的测试模块pub fn add(a: i32, b: i32) - i32 { a b } #[cfg(test)] mod tests { use super::*; use pretty_assertions::assert_eq; // crate for test-only use. Cannot be used in non-test code. #[test] fn test_add() { assert_eq!(add(2, 3), 5); } }这段代码中值得注意的关键点use super::*;是单元测试惯用法从外层模块导入被测代码仓库 单元测试章节 对此有专门说明use pretty_assertions::assert_eq;用局部导入覆盖了标准库的assert_eq!因此测试中直接写assert_eq!就会获得彩色 diff 输出注释明确写道 Cannot be used in non-test code——这是 dev-dependencies 作用域规则的直接体现下一节详述pretty_assertions扩展了标准库的assert_eq!与assert_ne!宏在断言失败时输出带颜色高亮的左右值 diff帮助快速定位差异。运行测试$ cargo testcargo test会编译并运行所有单元测试、集成测试和文档测试仓库 cargo 测试章节 展示了典型输出测试结果会按passed / failed / ignored / measured / filtered out汇总。作用域边界为什么测试依赖不能用于非测试代码在src/lib.rs的示例中pretty_assertions只能在#[cfg(test)] mod tests内使用。这是由 Cargo 的编译模型决定的#[cfg(test)]模块只在测试编译配置下才会被编译参见 unit_testing.md 对#[cfg(test)]属性的说明dev-dependencies 只出现在测试、示例、基准测试的编译上下文中如果在pub fn add等生产代码中尝试use pretty_assertions::assert_eq;cargo build/cargo check会直接报错——编译器找不到该 crate因为它根本没有被声明为正式依赖。这正是原文档特意在示例中加注释强调该点的原因。设计上这防止了测试专用代码悄悄渗入生产路径保证发布产物中不含任何测试辅助逻辑。三种测试风格下的 dev-dependencies 用法dev-dependencies 在 Rust 的三种测试风格中都能发挥价值1. 单元测试模块内如前例所示在src/lib.rs的#[cfg(test)] mod tests中使用。适合断言增强、mock 等辅助库。2. 集成测试tests/ 目录集成测试位于仓库根目录的tests/目录每个文件被编译为独立的 crate只能通过库的公共接口调用参见 integration_testing.md。dev-dependencies 同样对集成测试可见例如可以用assert_cmd测试 CLI 程序、用tempfile管理临时文件// tests/cli_test.rs #[test] fn test_cli_output() { // 这里可以直接 use 声明在 [dev-dependencies] 中的 crate }3. 文档测试doc comments 代码块文档注释中的代码块会被当作文档测试编译执行参见 doc_testing.md。若文档示例需要外部辅助 crate同样由 dev-dependencies 提供。dev-dependencies 的多种声明形式与普通依赖一样dev-dependencies 支持 Cargo 的全部依赖指定方式。仓库 Cargo 依赖章节 展示了三种来源的写法dev-dependencies 完全套用[dev-dependencies] pretty_assertions 1 # 来自 crates.io按版本指定 rand { git https://... } # 来自在线 git 仓库 bar { path ../bar } # 来自本地文件系统路径依赖版本遵循语义化版本Semantic Versioning约定。此外较新的 Cargo 版本还提供cargo add --dev crate快捷命令可直接把 crate 写入[dev-dependencies]省去手写 TOML 的步骤。注意事项与最佳实践隔离测试依赖与生产依赖凡是只在测试中使用的 crate一律放入[dev-dependencies]保持发布依赖树最小化这也是本主题的核心价值警惕测试并发cargo test默认并发运行多个测试仓库 cargo 测试章节 专门警告过这一点如果测试依赖涉及共享文件或端口要保证它们不会互相竞争例如写入同一个文件会导致内容交错调试失败信息测试失败时可用RUST_BACKTRACE1查看回溯配合pretty_assertions的彩色 diff 能更快定位左右值的差异区分 build-dependenciesCargo 还支持为构建脚本build script单独声明依赖相关机制见仓库 构建脚本章节。build-dependencies 服务于build.rs的编译而 dev-dependencies 服务于测试代码两者场景不同不要混用。小结dev-dependencies 是 Cargo 依赖管理体系中一个小而关键的机制它为测试、示例和基准测试提供专用依赖入口同时保证这些依赖不会传播给下游包。通过本仓库 dev_dependencies.md 中的pretty_assertions示例你已经掌握了从声明、编写到运行的完整流程。在真实项目中坚持测试依赖与生产依赖分离的原则能让你的依赖树更干净、构建更快、测试输出更专业。赞分享文档教程【免费下载链接】rust-by-exampleLearn Rust with examples (Live code editor included)项目地址https://gitcode.com/gh_mirrors/ru/rust-by-example点击查看免费下载相关推荐gh_mirrors/sh1/sh的依赖注入测试文档测试策略与示例gh_mirrors/sh1/sh的依赖注入测试文档测试策略与示例 引言 你是否在开发Shell脚本解析器、格式化器或解释器时遇到过测试复杂依赖关系的难题本开发工具CLIFastAPI 测试依赖覆盖全指南使用 app.dependency_overrides 在测试中替换 DependenciesFastAPI 测试依赖覆盖全指南使用 app.dependency_overrides 在测试中替换 Dependencies 本篇技术指南围绕 FastA后端Web框架API设计FastAPI依赖注入临时SQLitemodern-software-dev-assignments可测试单测写法详解FastAPI依赖注入临时SQLitemodern software dev assignments可测试单测写法详解 FastAPI 依赖注入 Depe示例工程上一篇GitBucket前端架构设计解决方案指南方法论与工具选型下一篇GitBucket版本管理战略解决方案指南工具与平台选型创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表