【架构讨论】内核测试框架：声明式环境配置与全局状态隔离

[miiyakumo]

【架构讨论】内核测试框架：声明式环境配置与全局状态隔离

类别：Architecture (架构) / Ideas (想法)

---

一、当前痛点与背景

目前我们的内核测试框架存在以下关键痛点，阻碍了快速、可靠的测试：

1. 强耦合与迟滞启动： 测试仅在所有子系统（包括堆、中断、调度器等）完全初始化之后才开始运行。
2. 定位困难： Bug 发生的地点（例如初始化代码）与错误被检出的地点（例如运行第一个测试用例时）可能相隔甚远，难以追踪问题的根源。
3. 副作用与隔离差： 测试之间高度依赖或共享全局状态，导致测试结果不可预测，且无法确保测试环境的干净。
4. 功能欠缺： 没有测试覆盖率等主流框架具有的功能

二、测试模块的预期与目标

我们提议对测试框架进行一次架构升级，目标是实现以下关键特性：

1. 最小环境执行（MTE）： 每个测试用例应仅在满足其最小环境依赖的条件下运行，例如只启用帧分配器，而不启用完整的堆。
2. 声明式配置： 开发者能够以声明式的方式指定测试所需的环境配置。
3. 运行时隔离： 保证测试之间不产生副作用，特别是对全局状态的修改能够自动还原（Teardown）。
4. 分层测试： 明确区分宿主 (std) 逻辑测试和目标 (no_std) 系统测试。
5. 覆盖率： 能够统计简单的代码测试覆盖率

三、需求清单（高层设计）

为了实现上述目标，我们需要引入以下机制：

ID	机制名称	核心作用	实现方法
D1	属性宏配置	提供 #[enable(...)] 语法，声明测试所需的最小环境。	Rust 过程宏 (Procedural Macro)
D2	环境抽象	抽象出所有全局状态和系统依赖的接口。	Rust Traits (如 TestEnvironment)
D3	RAII 守卫	确保环境在测试结束或 Panic 时能被可靠还原。	EnvGuard (利用 Drop Trait)
D4	配置解耦	将环境名称到 Setup/Teardown 逻辑的映射从宏主体中分离出来。	模块化环境结构体 + 过程宏内部的类型映射

四、使用示例（理想的测试代码）

我们期望未来的测试代码将具备如下清晰的依赖声明：

use our_test_macros::enable;

// 示例 1: 仅依赖于 Mock 内存分配，不依赖完整的堆管理器
#[enable(mock_frame_allocator, no_heap_trap_entry)]
fn test_minimal_context_switch_logic() {
    // 这段代码可以独立于完整的内核环境运行，且全局状态已被隔离/模拟。
    // ... 测试上下文切换的纯逻辑 ...
    assert!(true); 
}

// 示例 2: 测试需要完整的时钟和中断，但不需要堆分配
#[enable(enable_timer, enable_interrupt_controller)]
fn test_timer_initialization() {
    // ... 测试硬件交互和初始化逻辑 ...
    assert!(is_timer_working());
}

五、可能的实现方法（技术细节）

1. 属性宏 (#[enable]) 的工作流

属性宏将在编译期生成包装代码，实现 Setup -> Test -> Teardown 流程：

解析： 读取配置项（如 mock_frame_allocator）。

实例化： 宏生成代码，将配置项映射到具体的环境结构体实例（如 Box::new(MockFrameAllocator)）。

RAII 包装： 创建一个 EnvGuard 实例，持有这些环境实例。

执行：

调用所有环境实例的 setup() 方法。

运行原始测试函数。

函数退出时，EnvGuard 自动 drop，调用所有环境实例的 teardown() 方法，还原全局状态。

2. 全局状态隔离（D2 & D3）

开放讨论与后续步骤

请组织成员们对这个设计提问和反馈。特别是以下几个方面：

• 配置名称： 我们应如何命名这些配置项（例如 mock_frame_allocator 是否足够清晰）？

• 环境冲突： 如何在宏中优雅地处理环境冲突（例如 #[enable(mock_allocator, real_allocator)] 应该在编译时报错）？

• 核心 Trait 设计： TestEnvironment 的接口是否需要返回一个 Guard 对象，以实现更细粒度的 RAII？