Rust测试中如何Mock其他模块的私有结构体？

问题背景 #

我开发了一个包含多个职责独立领域的应用，核心约束与测试需求如下：

• auth领域的User结构体字段和new()构造函数仅对该领域私有，其他领域只能通过AuthService接口获取用户实例，避免领域逻辑被误用
• blog领域的函数分为两类：直接接收User入参（如get_posts_by_user()）、依赖AuthService获取用户（如get_posts_by_user_id()）
• 测试时需要脱离真实数据库依赖，MockAuthService以返回任意边界情况的User实例

此前尝试的方案均存在明显缺陷：

1. 公开User字段/构造函数：破坏领域封装，存在安全风险
2. auth领域编写专属Mock构造函数：代码重复，User结构变更时需同步维护，成本高
3. #[cfg(test)]复制结构体：代码冗余，生产与测试模式行为不一致（当前采用方案，可通过宏自动化）
4. 第三方库：未找到适配工具

推荐最佳实践 #

方案1：为测试场景提供专属构造入口 #

在auth模块中，通过#[cfg(test)]暴露一个仅测试可用的公共构造函数，复用生产环境的User结构体，避免代码重复：

pub mod auth {
    #[derive(Clone, Debug)]
    pub struct User {
        user_id: i32,
        username: String,
    }

    impl User {
        // 生产环境私有构造函数
        fn new(user_id: i32, username: String) -> User {
            User { user_id, username }
        }

        // 公开只读访问方法
        pub fn user_id(&self) -> i32 { self.user_id }
        pub fn username(&self) -> &str { &self.username }

        // 仅测试环境可见的构造函数
        #[cfg(test)]
        pub fn test_new(user_id: i32, username: String) -> User {
            Self::new(user_id, username)
        }
    }

    // AuthService、AuthImpl 代码保持不变
}

在blog的测试代码中，直接调用test_new()创建测试用User：

#[test]
fn test_get_posts_by_user() {
    let blog = BlogImpl;
    let user = User::test_new(42, "Dummy".to_string());
    let posts = blog.get_posts_by_user(&user);
    assert_eq!(posts, vec!["Hi, my name is Dummy (id: 42)"]);
}

优势：

• 完全复用生产代码，无冗余
• 生产环境下构造逻辑完全私有，无封装泄露
• 测试代码简洁，维护成本低

方案2：限制可见性至当前Crate #

如果所有测试代码都在同一个 crate 内，可将测试构造函数的可见性设为pub(crate)，进一步缩小暴露范围：

#[cfg(test)]
pub(crate) fn test_new(user_id: i32, username: String) -> User {
    Self::new(user_id, username)
}

优势：可见性更严格，避免跨crate的测试代码误用。

方案3：宏自动生成测试构造函数 #

针对数十个私有类型的场景，编写宏批量生成测试构造函数，减少手动重复工作：

#[cfg(test)]
macro_rules! test_ctor {
    ($struct_name:ident, ($($field:ident: $ty:ty),*)) => {
        impl $struct_name {
            pub fn test_new($($field: $ty),*) -> Self {
                Self { $($field),* }
            }
        }
    };
}

// 在User模块中调用宏
#[cfg(test)]
test_ctor!(User, (user_id: i32, username: String));

优势：

• 批量处理大量私有结构体，代码冗余极低
• 结构体字段变更时，仅需更新宏调用参数，维护成本极低

方案4：Mock AuthService而非直接构造User #

对于依赖AuthService的函数，直接Mock服务返回值，结合测试构造函数实现更简洁的测试：

#[cfg(test)]
mod tests {
    use crate::auth::{AuthService, User};
    use super::*;

    struct AuthMock {
        expected_user: User,
    }

    impl AuthService for AuthMock {
        fn get_user(&self, _user_id: i32) -> User {
            self.expected_user.clone()
        }
    }

    #[test]
    fn test_get_posts_by_user_id() {
        let blog = BlogImpl;
        let test_user = User::test_new(1337, "Admin".to_string());
        let auth_mock = AuthMock { expected_user: test_user };
        let posts = blog.get_posts_by_user_id(auth_mock, 1);
        assert_eq!(posts, vec!["Hi, my name is Admin (id: 1337)"]);
    }
}

方案对比总结 #

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