comprehensive-rust 课程中的 Chromium Rust 测试方案rust_gtest_interop 库深度解析【免费下载链接】comprehensive-rustThis is the Rust course used by the Android team at Google. It provides you the material to quickly teach Rust.项目地址: https://gitcode.com/GitHub_Trending/co/comprehensive-rust本篇技术指南聚焦 Google 开源 Rust 课程comprehensive-rustChromium 专题中的 rust-gtest-interop.md 文档系统讲解 Chromium 中如何借助rust_gtest_interop库用 Rust 编写gtest测试用例。文章将带你掌握#[gtest(...)]属性宏、expect_eq!断言族的用法并结合仓库内配套的 testing.md、build-gn.md 与 chromium-import-macro.md 文档理解 Chromium 对 Rust 代码的三种测试策略、GN 构建规则及 crate 导入机制最终具备在 Chromium 工程中编写、构建和运行 Rustgtest测试的完整实战能力。背景Chromium 与 Rust 社区在测试组织方式上的差异Rust 社区惯例与源码同文件的单元测试模块Rust 社区通常把单元测试写在与被测代码相同的源文件内的mod tests模块中如课程 testing.md 前文所讲的那样#[cfg(test)] mod tests { #[test] fn my_test() { todo!() } }Chromium 惯例测试与被测代码分离Chromium 中单元测试习惯上放在独立的源文件中Rust 代码也延续了这一实践。这样做的两个好处见 testing.md测试可发现性一致测试位置统一、可预期便于在庞大代码库中定位避免二次编译独立文件避免了.rs文件在test配置下被重复编译。Chromium 中测试 Rust 代码的三种策略课程文档 testing.md 明确给出了 Chromium 中测试 Rust 代码的三种可选方案方案说明适用场景原生 Rust 测试#[test]Rust 社区标准方式在//third_party/rust之外不推荐使用C 编写的gtest测试通过 FFI 调用 Rust 函数Rust 代码只是薄薄的 FFI 胶水层已有单元测试覆盖足够Rust 编写的gtest测试通过被测 crate 的公开 API 测试必要时使用pub mod for_testing { ... }需要为 Rust 实现编写独立测试这正是本专题接下来几页的主题文档中还给出了两条重要的决策参考第三方 crate 的原生 Rust 测试最终应当由 Chromium 的 CI 机器人执行——不过这种需求很少出现通常只在新增或更新第三方 crate 时才有实际案例QR 功能在 Chromium 自研 Rust 层几乎没有逻辑只是薄薄的 FFI 粘合代码因此沿用现有 C 单元测试通过ScopedFeatureList参数化测试来开关 Rust 实现而假设中的 PNG 集成方案若需要libpng有而pngcrate 缺失的内存安全像素变换如 RGBA→BGRA、gamma 校正则更适合用 Rust 编写独立测试。rust_gtest_interop库核心能力rust-gtest-interop.md 指出rust_gtest_interop库源码位于 Chromium 的//testing/rust_gtest_interop/提供两类核心能力把 Rust 函数当作gtest测试用例通过#[gtest(...)]属性宏实现使用expect_eq!等断言宏用法类似assert_eq!但断言失败时不会 panic、也不会终止测试。最小示例use rust_gtest_interop::prelude::*; #[gtest(MyRustTestSuite, MyAdditionTest)] fn test_addition() { expect_eq!(2 2, 4); }逐行拆解这个示例use rust_gtest_interop::prelude::*;引入库的 prelude其中导出#[gtest]属性宏与expect_eq!等断言宏#[gtest(MyRustTestSuite, MyAdditionTest)]第一个参数是测试套件test suite名第二个参数是测试用例名。编译后该 Rust 函数会被注册为 Cgtest框架中的一个测试用例在gtest的测试过滤、sharding、输出报告中以MyRustTestSuite.MyAdditionTest形式出现expect_eq!(2 2, 4)非 panic 断言失败时记录失败信息并继续执行当前测试函数区别于assert_eq!的立即中止语义。与assert_eq!的语义差异不 panic、不终止测试课程文档强调expect_eq!是 similar toassert_eq!but not panicking and not terminating the test when the assertion fails。这一设计在gtest生态中意义重大gtest的惯例是单个测试函数内可以有多条断言断言失败只标记该测试为失败而不中断后续断言的执行从而在一次测试运行中尽可能多地暴露问题原生 Rust 的assert_eq!失败即 panic 中止若测试函数内有多处断言只能看到第一处失败因此expect_eq!一族宏expect_eq!及similar macros即expect_ne!、expect_true!/expect_false!等同类非终止断言让 Rust 测试的行为与 Cgtest测试保持一致。用 GN 把 Rust gtest 测试接入构建方式一并入已有 C 测试二进制最简单的方式是把 Rust 测试文件直接加入一个已包含 C 测试的现有testtarget见 build-gn.mdtest(ui_base_unittests) { ... sources [ my_rust_lib_unittest.rs ] deps [ :my_rust_lib ] }方式二独立的 Rust 测试 static_library把 Rust 测试单独放到一个rust_static_library中同样可行但需要手动声明对支持库的依赖rust_static_library(my_rust_lib_unittests) { testonly true is_gtest_unittests true crate_root my_rust_lib_unittest.rs sources [ my_rust_lib_unittest.rs ] deps [ :my_rust_lib, //testing/rust_gtest_interop, ] } test(ui_base_unittests) { ... deps [ :my_rust_lib_unittests ] }关键点说明testonly true标记该库仅用于测试is_gtest_unittests true告诉构建系统这是一个gtest单元测试库使rust_gtest_interop的注册代码正确接入gtest框架deps中显式加入//testing/rust_gtest_interop支持库这正是本篇文章主题库的 GN target最终仍需某个testtarget 把该rust_static_library链接进测试二进制。用chromium::import!宏导入被测 crate测试文件通常需要引用被测 crate 的公开 API。由于 Chromium 中的rust_static_library默认不显式指定crate_name其 crate 名由完整 target 路径和名称推导而来直接书写往往冗长难用。chromium-import-macro.md 给出了解决方案——使用自动导入的chromiumcrate 中的chromium::import!宏chromium::import! { //ui/base:my_rust_lib; } use my_rust_lib::my_function_under_test;该宏在底层展开后大致等价于extern crate ui_sbase_cmy_urust_ulib as my_rust_lib; use my_rust_lib::my_function_under_test;展开示例中经过字符变换的 crate 名只是示意用于说明为什么直接书写推导出的 crate 名很不方便。为什么建议用 import! 而不是显式 crate_name文档指出rust_static_library支持通过crate_name属性指定显式名称但这种做法不被推荐因为 crate 名必须全局唯一。crates.io 天然保证 crate 名唯一因此由gnrt工具课程 cargo.md 中有讲解生成的cargo_crateGN target 可以使用简短 crate 名而 Chromium 自研 target 则统一走chromium::import!宏避免手工维护易冲突的全局唯一名称。完整实战组合一个可运行的测试流程综合上述内容在 Chromium 中为一个 Rust 库编写gtest测试的完整链路为准备环境按 setup.md 完成 Chromium 构建配置要求代码较新commit position 1223636 之后即 2023 年 11 月之后推荐 component/debug 构建以加快迭代gn gen out/Debug autoninja -C out/Debug chrome编写被测库创建my_rust_librust_static_library导出待测函数编写测试文件my_rust_lib_unittest.rsuse rust_gtest_interop::prelude::*; chromium::import! { //ui/base:my_rust_lib; } use my_rust_lib::my_function_under_test; #[gtest(MyRustLibTestSuite, MyFunctionWorks)] fn test_my_function() { expect_eq!(my_function_under_test(), 42); }接入构建按上文方式一或方式二修改 GN 文件方式二记得在deps中加入//testing/rust_gtest_interop构建并运行测试autoninja -C out/Debug ui_base_unittests随后直接运行该测试二进制Rust 测试即以gtest用例形式被发现和执行。与 Chromium 测试生态的衔接总结rust_gtest_interop是 Chromium 中 Rust 代码也要遵守 Chromium 测试惯例 这一设计理念的关键落地组件测试文件独立于源码与其他 C 测试一样通过 GN target 组织Rust 测试注册进统一的gtest框架与 C 测试共享测试发现、过滤、结果报告等基础设施expect_eq!等非终止断言让 Rust 侧行为对齐 Cgtest的断言语义配合chromium::import!宏可以干净地跨 target 引用被测 crate而无需处理全局唯一 crate 名的负担。如果你正在 Chromium 中开发 Rust 功能且需要为 Rust 实现本身编写覆盖测试那么以 rust-gtest-interop.md 为起点结合 build-gn.md 的构建规则与 chromium-import-macro.md 的导入机制即可快速搭建起一套符合 Chromium 工程惯例的 Rust 测试体系。【免费下载链接】comprehensive-rustThis is the Rust course used by the Android team at Google. It provides you the material to quickly teach Rust.项目地址: https://gitcode.com/GitHub_Trending/co/comprehensive-rust创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
comprehensive-rust 课程中的 Chromium Rust 测试方案rust_gtest_interop 库深度解析【免费下载链接】comprehensive-rustThis is the Rust course used by the Android team at Google. It provides you the material to quickly teach Rust.项目地址: https://gitcode.com/GitHub_Trending/co/comprehensive-rust本篇技术指南聚焦 Google 开源 Rust 课程comprehensive-rustChromium 专题中的 rust-gtest-interop.md 文档系统讲解 Chromium 中如何借助rust_gtest_interop库用 Rust 编写gtest测试用例。文章将带你掌握#[gtest(...)]属性宏、expect_eq!断言族的用法并结合仓库内配套的 testing.md、build-gn.md 与 chromium-import-macro.md 文档理解 Chromium 对 Rust 代码的三种测试策略、GN 构建规则及 crate 导入机制最终具备在 Chromium 工程中编写、构建和运行 Rustgtest测试的完整实战能力。背景Chromium 与 Rust 社区在测试组织方式上的差异Rust 社区惯例与源码同文件的单元测试模块Rust 社区通常把单元测试写在与被测代码相同的源文件内的mod tests模块中如课程 testing.md 前文所讲的那样#[cfg(test)] mod tests { #[test] fn my_test() { todo!() } }Chromium 惯例测试与被测代码分离Chromium 中单元测试习惯上放在独立的源文件中Rust 代码也延续了这一实践。这样做的两个好处见 testing.md测试可发现性一致测试位置统一、可预期便于在庞大代码库中定位避免二次编译独立文件避免了.rs文件在test配置下被重复编译。Chromium 中测试 Rust 代码的三种策略课程文档 testing.md 明确给出了 Chromium 中测试 Rust 代码的三种可选方案方案说明适用场景原生 Rust 测试#[test]Rust 社区标准方式在//third_party/rust之外不推荐使用C 编写的gtest测试通过 FFI 调用 Rust 函数Rust 代码只是薄薄的 FFI 胶水层已有单元测试覆盖足够Rust 编写的gtest测试通过被测 crate 的公开 API 测试必要时使用pub mod for_testing { ... }需要为 Rust 实现编写独立测试这正是本专题接下来几页的主题文档中还给出了两条重要的决策参考第三方 crate 的原生 Rust 测试最终应当由 Chromium 的 CI 机器人执行——不过这种需求很少出现通常只在新增或更新第三方 crate 时才有实际案例QR 功能在 Chromium 自研 Rust 层几乎没有逻辑只是薄薄的 FFI 粘合代码因此沿用现有 C 单元测试通过ScopedFeatureList参数化测试来开关 Rust 实现而假设中的 PNG 集成方案若需要libpng有而pngcrate 缺失的内存安全像素变换如 RGBA→BGRA、gamma 校正则更适合用 Rust 编写独立测试。rust_gtest_interop库核心能力rust-gtest-interop.md 指出rust_gtest_interop库源码位于 Chromium 的//testing/rust_gtest_interop/提供两类核心能力把 Rust 函数当作gtest测试用例通过#[gtest(...)]属性宏实现使用expect_eq!等断言宏用法类似assert_eq!但断言失败时不会 panic、也不会终止测试。最小示例use rust_gtest_interop::prelude::*; #[gtest(MyRustTestSuite, MyAdditionTest)] fn test_addition() { expect_eq!(2 2, 4); }逐行拆解这个示例use rust_gtest_interop::prelude::*;引入库的 prelude其中导出#[gtest]属性宏与expect_eq!等断言宏#[gtest(MyRustTestSuite, MyAdditionTest)]第一个参数是测试套件test suite名第二个参数是测试用例名。编译后该 Rust 函数会被注册为 Cgtest框架中的一个测试用例在gtest的测试过滤、sharding、输出报告中以MyRustTestSuite.MyAdditionTest形式出现expect_eq!(2 2, 4)非 panic 断言失败时记录失败信息并继续执行当前测试函数区别于assert_eq!的立即中止语义。与assert_eq!的语义差异不 panic、不终止测试课程文档强调expect_eq!是 similar toassert_eq!but not panicking and not terminating the test when the assertion fails。这一设计在gtest生态中意义重大gtest的惯例是单个测试函数内可以有多条断言断言失败只标记该测试为失败而不中断后续断言的执行从而在一次测试运行中尽可能多地暴露问题原生 Rust 的assert_eq!失败即 panic 中止若测试函数内有多处断言只能看到第一处失败因此expect_eq!一族宏expect_eq!及similar macros即expect_ne!、expect_true!/expect_false!等同类非终止断言让 Rust 测试的行为与 Cgtest测试保持一致。用 GN 把 Rust gtest 测试接入构建方式一并入已有 C 测试二进制最简单的方式是把 Rust 测试文件直接加入一个已包含 C 测试的现有testtarget见 build-gn.mdtest(ui_base_unittests) { ... sources [ my_rust_lib_unittest.rs ] deps [ :my_rust_lib ] }方式二独立的 Rust 测试 static_library把 Rust 测试单独放到一个rust_static_library中同样可行但需要手动声明对支持库的依赖rust_static_library(my_rust_lib_unittests) { testonly true is_gtest_unittests true crate_root my_rust_lib_unittest.rs sources [ my_rust_lib_unittest.rs ] deps [ :my_rust_lib, //testing/rust_gtest_interop, ] } test(ui_base_unittests) { ... deps [ :my_rust_lib_unittests ] }关键点说明testonly true标记该库仅用于测试is_gtest_unittests true告诉构建系统这是一个gtest单元测试库使rust_gtest_interop的注册代码正确接入gtest框架deps中显式加入//testing/rust_gtest_interop支持库这正是本篇文章主题库的 GN target最终仍需某个testtarget 把该rust_static_library链接进测试二进制。用chromium::import!宏导入被测 crate测试文件通常需要引用被测 crate 的公开 API。由于 Chromium 中的rust_static_library默认不显式指定crate_name其 crate 名由完整 target 路径和名称推导而来直接书写往往冗长难用。chromium-import-macro.md 给出了解决方案——使用自动导入的chromiumcrate 中的chromium::import!宏chromium::import! { //ui/base:my_rust_lib; } use my_rust_lib::my_function_under_test;该宏在底层展开后大致等价于extern crate ui_sbase_cmy_urust_ulib as my_rust_lib; use my_rust_lib::my_function_under_test;展开示例中经过字符变换的 crate 名只是示意用于说明为什么直接书写推导出的 crate 名很不方便。为什么建议用 import! 而不是显式 crate_name文档指出rust_static_library支持通过crate_name属性指定显式名称但这种做法不被推荐因为 crate 名必须全局唯一。crates.io 天然保证 crate 名唯一因此由gnrt工具课程 cargo.md 中有讲解生成的cargo_crateGN target 可以使用简短 crate 名而 Chromium 自研 target 则统一走chromium::import!宏避免手工维护易冲突的全局唯一名称。完整实战组合一个可运行的测试流程综合上述内容在 Chromium 中为一个 Rust 库编写gtest测试的完整链路为准备环境按 setup.md 完成 Chromium 构建配置要求代码较新commit position 1223636 之后即 2023 年 11 月之后推荐 component/debug 构建以加快迭代gn gen out/Debug autoninja -C out/Debug chrome编写被测库创建my_rust_librust_static_library导出待测函数编写测试文件my_rust_lib_unittest.rsuse rust_gtest_interop::prelude::*; chromium::import! { //ui/base:my_rust_lib; } use my_rust_lib::my_function_under_test; #[gtest(MyRustLibTestSuite, MyFunctionWorks)] fn test_my_function() { expect_eq!(my_function_under_test(), 42); }接入构建按上文方式一或方式二修改 GN 文件方式二记得在deps中加入//testing/rust_gtest_interop构建并运行测试autoninja -C out/Debug ui_base_unittests随后直接运行该测试二进制Rust 测试即以gtest用例形式被发现和执行。与 Chromium 测试生态的衔接总结rust_gtest_interop是 Chromium 中 Rust 代码也要遵守 Chromium 测试惯例 这一设计理念的关键落地组件测试文件独立于源码与其他 C 测试一样通过 GN target 组织Rust 测试注册进统一的gtest框架与 C 测试共享测试发现、过滤、结果报告等基础设施expect_eq!等非终止断言让 Rust 侧行为对齐 Cgtest的断言语义配合chromium::import!宏可以干净地跨 target 引用被测 crate而无需处理全局唯一 crate 名的负担。如果你正在 Chromium 中开发 Rust 功能且需要为 Rust 实现本身编写覆盖测试那么以 rust-gtest-interop.md 为起点结合 build-gn.md 的构建规则与 chromium-import-macro.md 的导入机制即可快速搭建起一套符合 Chromium 工程惯例的 Rust 测试体系。【免费下载链接】comprehensive-rustThis is the Rust course used by the Android team at Google. It provides you the material to quickly teach Rust.项目地址: https://gitcode.com/GitHub_Trending/co/comprehensive-rust创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
