如何在Rust文件中使用子模块组织单元测试？

可行性与配置注解问题 #

Cargo完全支持用子模块归类单元测试代码，这种做法完全可行。关于#[cfg(test)]的添加：

• 只需要在顶层测试模块上添加一次该注解即可，它的编译条件会自动继承给所有子模块，子模块不需要重复添加。

举个实际的代码示例：

// 核心业务代码
fn add(a: i32, b: i32) -> i32 {
    a + b
}

fn multiply(a: i32, b: i32) -> i32 {
    a * b
}

// 顶层测试模块，仅此处添加#[cfg(test)]
#[cfg(test)]
mod tests {
    use super::*;

    // 按功能拆分的测试子模块：加法测试
    mod add_tests {
        use super::*;

        #[test]
        fn positive_numbers() {
            assert_eq!(add(2, 3), 5);
        }

        #[test]
        fn negative_numbers() {
            assert_eq!(add(-2, -3), -5);
        }
    }

    // 按功能拆分的测试子模块：乘法测试
    mod multiply_tests {
        use super::*;

        #[test]
        fn positive_numbers() {
            assert_eq!(multiply(2, 3), 6);
        }

        #[test]
        fn multiply_by_zero() {
            assert_eq!(multiply(2, 0), 0);
        }
    }
}

最佳实践说明 #

这种按子模块归类测试的写法完全符合Rust最佳实践：

• 当文件内函数及测试用例数量较多时，按功能/函数拆分测试子模块，能让测试代码结构更清晰，便于后续维护和快速定位特定测试用例。
• VS Code的代码透镜能识别并运行这些子模块内的测试，说明语法和编译逻辑是正确的，执行cargo test时，Cargo也会自动遍历所有子模块中的测试用例并执行。

如果有特殊需求（比如某个子模块仅在特定编译目标下运行），可以单独给子模块添加#[cfg(...)]条件，但常规场景下，顶层的#[cfg(test)]已经足够覆盖所有测试子模块的编译需求。

内容的提问来源于stack exchange，提问作者Jiulia