容器运行时云原生【免费下载链接】youkiA container runtime written in Rust项目地址https://gitcode.com/gh_mirrors/yo/youki点击查看免费下载test_framework 是 youki 仓库中为将 OCI 集成测试移植到 Rust 而专门开发的轻量测试框架crate它提供 TestResult、Testable / TestableGroup 两条核心 trait以及 Test、ConditionalTest、TestGroup、TestManager 等开箱即用的构件默认借助 crossbeam 并行执行测试组与组内测试。读完本文你将掌握该框架的完整设计从测试单元、分组到调度与结果打印、如何在 contest 测试二进制中注册与筛选测试以及如何为需要按顺序执行或有状态依赖的测试如容器生命周期自定义 trait 实现。框架定位为 OCI 集成测试的 Rust 移植而生该框架最初位于/tests/test_framework当前仓库中实际位置为 tests/contest/test_framework其定位在 docs/src/developer/e2e/test_framework.md 中写得很明确专门为把 OCI 集成测试原 runc / runtime-tools 生态中的测试集移植到 Rust 而开发的测试框架。它包含三类核心结构表示单个测试的 struct表示一组测试的 group struct负责实际运行测试的 test manager。同时框架对外暴露 trait允许在需要时实现自定义的测试结构或测试组结构从而获得对测试执行的精细控制。配套的 tests/contest/test_framework/README.md 提供了各 struct 与 trait 的文档说明是本篇讲解的一手依据。从 tests/contest/test_framework/Cargo.toml 可以看到它的依赖非常精简[dependencies] anyhow { workspace true } crossbeam { workspace true } num_cpus { workspace true }其中crossbeam是并行执行测试组的并发原语num_cpus用于按 CPU 核数分批调度并行测试组anyhow承担错误处理——这正是下文要展开的三条主线。最小测试单元TestResult 与 Testable框架的最小单元是一个可测试Testable的东西。tests/contest/test_framework/src/testable.rs 定义了结果类型与两条 trait。TestResult带 Skip 语义的结果枚举TestResult类似于 Rust 标准库的Result但有两点不同Ok变体不带任何关联值直接命名为Passed并且增加了Skipped变体用于表示测试因环境原因被跳过pub enum TestResult { /// Test was ok Passed, /// Test needed to be skipped Skipped(String), /// Test was error Failed(Error), }同时实现了FromResultT因此测试函数内部用anyhow::Result编写的代码可以直接通过.into()转换为TestResult这也解释了 container_lifecycle.rs 中create::create(...).into()的写法。Testable单个测试的契约pub trait Testable { fn get_name(self) - static str; fn can_run(self) - bool { true } fn run(self) - TestResult; }实现者必须提供三个函数函数作用默认行为get_name返回测试名称static str同时作为分组内 BTreeMap 的 key无默认必须实现can_run返回该测试当前环境能否运行默认恒为truerun执行真正的测试逻辑返回TestResult无默认必须实现can_run返回false时调度方不会调用run而是直接产出TestResult::Skipped(test cannot run in the current environment ...)见下文 TestGroup 实现。TestableGroup测试分组与命名空间pub trait TestableGroup { fn get_name(self) - static str; fn parallel(self) - bool; fn run_all(self) - Vec(static str, TestResult); fn run_selected(self, selected: [str]) - Vec(static str, TestResult); }分组不仅用于把测试按模块聚合还承担命名空间职责例如cgroup_v2_cpu、seccomp、terminal等分组名。注意与 README 的旧说明相比当前源码中的TestableGroup多了一个parallel()方法用于声明该组是否允许并行执行——这是实现并行/串行调度的关键开关。开箱即用的构件Test、ConditionalTest、TestGroup、TestManager框架为最常见的场景提供了四个现成结构避免重复造轮子。Test无状态简单测试模板tests/contest/test_framework/src/test.rs 中Test持有名称与一个 Box 化的测试函数new接收name和Boxdyn Fn() - TestResult Sync Send。它实现Testablerun直接调用闭包。适合总是运行、不需要状态信息的测试。ConditionalTest条件性测试模板tests/contest/test_framework/src/conditional_test.rs 中ConditionalTest::new接收三个参数pub fn new(name: static str, check_fn: BoxCheckFn, test_fn: BoxTestFn) - Selfcheck_fn: Boxdyn Fn() - bool Sync Send条件函数返回该测试能否运行test_fn实际测试函数。它实现Testable时把can_run()委托给check_fn。典型应用如 cgroups/cpu/v2.rs其中每个 CPU 测试都是ConditionalTest::new条件函数用于检测当前环境是否支持对应 cgroup v2 特性如 CPU idle、weight、quota、period 的配置能力。TestGroup默认并行执行的测试组tests/contest/test_framework/src/test_group.rs 中TestGroup内部用BTreeMapstatic str, Boxdyn Testable Sync Send存储测试按名称有序并提供new(name)创建组parallel默认为trueset_nonparallel()显式标记该组不适合并行执行add(VecBoximpl Testable Sync Send static)批量加入测试。其run_all/run_selected在parallel true时使用crossbeam::thread::scope为每个测试派生线程并发执行先全部spawn再逐个join收集结果每个线程内先检查can_run()不满足则记录Skippedparallel false时则退化为顺序执行。也就是说默认情况下组内单个测试也是并行的只有主动调用set_nonparallel才会串行。TestManager测试总调度与结果打印tests/contest/test_framework/src/test_manager.rs 是框架的大脑持有所有测试组与清理回调负责调度和打印。主要接口方法作用new()/Default创建空的 manageradd_test_group(BoxTestableGroupType)注册一个测试组add_cleanup(Boxdyn Fn() - Result())注册清理回调全部测试结束后执行run_all()运行所有can_run通过的组的全部测试并打印结果run_selected(Vec(str, OptionVecstr))只运行选中的组/测试tests_groups() - VecString列出所有已注册的组名供 list 子命令使用run_all的调度逻辑很讲究先收集所有parallel()为 true 的组按num_cpus::get().max(1)作为批次大小分批每个批次内部用crossbeam::thread::scope并行运行各组再次体现 crossbeam 的核心作用组间也并行全部并行组结束后再顺序运行所有非并行组最后依次执行所有 cleanup 回调失败时打印Failed to cleanup: {e}。run_selected接收(组名, Option测试名列表)元组向量None表示运行该组全部测试Some(names)则只运行选中测试未找到的组会向 stderr 打印Error : Test Group {name} not found, skipping。结果打印采用 TAP 风格Test Anything Protocol的格式来自print_test_result# Start group cgroup_v2_cpu 1 / 8 : test_cpu_idle_set : ok 2 / 8 : test_cpu_weight_valid_set : not ok assertion failed: ... # End group cgroup_v2_cpu其中Passed打印okSkipped打印skipped并附原因Failed打印not ok并附错误内容。并行与串行的取舍为什么需要自定义实现原文档特别强调默认的 Test、ConditionalTest、TestGroup 都是为无状态测试设计的默认并行行为并不总是合适的。最典型的反例是容器生命周期测试——一个容器必须先 create 再 start 才能 stop测试之间存在严格的前后依赖并行执行必然导致失败。此时有两种应对方式标记串行组对依然无状态但需按序的组可在组内调用set_nonparallel()。但run_all的顺序是 BTreeMap 的字典序不一定等于业务需要的顺序自定义实现 trait在自定义 struct 上实现TestableGroup必要时实现Testable在run_all/run_selected内部自己编排顺序从而获得对测试运行方式的精细控制。仓库中的 ContainerLifecycle 就是第二类做法的实例它并非简单的TestGroup而是一个自带状态container_id、project_path: tempfile::TempDir的自定义结构通过create()、start()、kill()等方法按生命周期顺序编排并配合NetnsGuard这类 RAII guard 在测试结束Drop时自动清理网络命名空间。这也是原文档所述实现相应 trait 以获得精细控制的最佳注脚。便利宏test_result! 与 assert_result_eq!为了减少样板代码testable.rs 还导出了两个宏test_result!($e)对anyhow::Result表达式求值出错时立即return TestResult::Failed(err)成功则解包出值——在 cgroups/cpu/v2.rs 中被大量用于创建 spec → 创建容器 → 校验 cgroup 值的链式调用assert_result_eq!(expected, actual[, fmt_args...])比较两个值是否相等不等时构造assertion failed: expected: ... actual: ...的anyhow::Error并配合?/test_result!向上传播。两者结合使测试体可以写成顺序步骤 即时失败的直白风格错误信息自带预期值与实际值便于定位。实战接线contest 测试二进制的组装方式框架的消费者是contest测试程序入口为 tests/contest/contest/src/main.rs。组装流程清晰展示了框架的完整用法let mut tm TestManager::new();创建管理器逐个构造测试组TestGroup::new(cgroup_v2_cpu)无状态组或ContainerLifecycle::new()有状态自定义组通过tm.add_test_group(Box::new(...))注册约 60 个测试组覆盖 cgroups、seccomp、hooks、mount、uid_mappings、checkpoint_restore、update、time_ns 等模块tm.add_cleanup(Box::new(cgroups::cleanup_v2))注册统一的 cgroup v2 清理回调根据子命令分发run子命令带--runtime、--runtimetest、--tests参数调用run_all或run_selectedlist子命令调用tests_groups()打印所有分组名。其中parse_testsmain.rs把命令行传入的测试选择字符串解析成run_selected需要的元组形式group::test1,test2按::拆分为组名 测试名列表仅group则代表整组。例如--tests cgroup_v2_cpu::test_cpu_idle_set,test_cpu_weight_valid_set seccomp会并行运行cgroup_v2_cpu组内的两个选中测试以及整个seccomp组。若要并行运行多个测试组可通过本框架继续扩展TestableGroup实现或在contest的main.rs中按parse_tests的语法传递多个分组。小结设计核心Testable定义最小测试单元TestableGroup提供分组与命名空间TestManager统一调度三者都以 trait 形式开放便于按需替换。并行策略默认组间、组内都并行crossbeam num_cpus 分批需要顺序执行时用set_nonparallel或自定义 trait 实现。结果语义TestResult三态Passed / Skipped / Failed配合test_result!、assert_result_eq!宏让集成测试既简洁又可读。落地实例contest 二进制注册约 60 个测试组覆盖 youki 的 cgroups、seccomp、生命周期、checkpoint/restore 等关键能力是验证运行时 OCI 兼容性的主战场。如需进一步了解该框架在更大测试体系中的位置可继续阅读 tests/contest/test_framework/README.md 以及 docs/src/developer/e2e 目录下的集成测试与测试框架文档若要查看全部被调度的测试组清单直接运行contest list即可。赞分享容器运行时云原生【免费下载链接】youkiA container runtime written in Rust项目地址https://gitcode.com/gh_mirrors/yo/youki点击查看免费下载相关推荐youki 集成测试框架 test_framework 完全指南从 Testable 到 TestManager 的并行测试体系youki 集成测试框架 test_framework 完全指南从 Testable 到 TestManager 的并行测试体系 本文以 tests/cont容器运行时云原生Spock框架并行测试执行深度解析Spock框架并行测试执行深度解析 并行测试概述 Spock框架从2.0版本开始基于JUnit平台实现了并行测试执行功能这是一个实验性特性。通过并行执行测试Octicons与Bulma CSS集成框架兼容性测试Octicons与Bulma CSS集成框架兼容性测试 在现代Web开发中图标系统与CSS框架的兼容性直接影响开发效率和界面一致性。Octicons作为GiUI组件前端上一篇如何理解Uniswap V3 Core的无委托调用安全机制完整防御指南下一篇Multiverso未来路线图下一代分布式训练技术前瞻创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考