当前位置：首页 > news >正文

你的测试又慢又不可靠-因为你测错了东西

news 2025/9/13 21:02:50

GitHub 主页

你的测试又慢又不可靠？因为你测错了东西！🧪➡️✅

“我们应该写更多的测试。”

在每一个技术会议上，这句话都会被反复提起，就像一句神圣的咒语。人人都点头称是，人人都知道这是“正确”的。但一回到座位上，很多人脸上的表情就变得痛苦起来。😫

为什么？因为在很多项目中，写测试是一件苦差事。测试跑得像乌龟一样慢，一个完整的测试套件跑下来，够你泡三杯咖啡了。☕️ 测试代码本身，比业务代码还复杂、还难懂。最要命的是，这些测试非常“脆弱”，你只是在前端改了一个 CSS 类名，或者在 JSON 响应里加了一个字段，上百个测试就莫名其妙地挂掉了。💔

如果你对这些场景感同身受，那么，我这个老家伙想告诉你一个秘密：你的测试之所以那么糟糕，问题可能不在于测试本身，而在于你的应用程序架构，让测试变得异常困难。 而一个好的框架，它的核心价值之一，就是引导你构建一个“可测试”的架构。

“错误”的测试方式：执着于通过 UI 和 HTTP 来测试一切

很多开发者，尤其是刚入行不久的，理解的“测试”就是“模拟用户的行为”。所以，他们会写大量的测试，来自动化地做这些事情：

启动一个完整的 Web 服务器。
（对于后端）发送一个真实的 HTTP 请求到某个端点。
（对于前端）启动一个浏览器，找到某个按钮，点击它。
断言返回的 HTTP 状态码、JSON 内容或者页面上的某个文字是否符合预期。

在 Node.js 世界里，用supertest这样的库来测试一个 Express 应用，就是这种思想的典型代表。

// An example of testing via HTTP
const request = require('supertest');
const app = require('../app'); // Your entire Express appdescribe('POST /users', () => {it('should create a new user', async () => {const response = await request(app).post('/users').send({ username: 'test', password: 'password' });expect(response.statusCode).toBe(201);expect(response.body.username).toBe('test');});
});

这种测试，我们称之为“端到端测试”或“集成测试”。它们有没有用？当然有！它们能验证整个系统的所有部分是否能正确地协同工作。但如果你的测试策略只依赖于这种测试，那你就大错特错了。为什么？

慢！慢！慢！ 启动服务器、建立网络连接、序列化和反序列化 JSON……每一步都需要时间。一个测试可能需要几十甚至几百毫秒。当你有成百上千个测试时，总时间就会变成几分钟甚至更长。这会严重拖慢你的开发反馈循环。
脆弱！ 它们与外部细节（UI 结构、API 契约）耦合得太紧了。API 响应多了一个字段，测试就可能失败。这种测试关心的是“表现形式”，而不是“内在逻辑”。
难以覆盖角落案例！ 你的核心业务逻辑，可能有很多分支和异常情况。比如，“如果数据库在用户创建后、发送欢迎邮件前，突然挂了，会发生什么？” 这种场景，想通过 HTTP 请求来精确地模拟，几乎是不可能的。你总不能为了跑测试，真的去拔数据库的网线吧？

“正确”的测试之道：金字塔与分层解耦

正确的测试策略，应该像一个金字塔。底部是大量的、快速的、可靠的单元测试，中间是少量的集成测试，顶端是极少数的端到端测试。

测试金字塔

而实现这个金字塔的关键，就在于我们上一篇文章讨论的分层架构。一个设计良好的应用，它的核心业务逻辑，应该与外部世界（比如 Web 框架、数据库）完全解耦。

这就是 Hyperlane 蓝图的威力所在。它鼓励你把最珍贵、最复杂的逻辑，放在service和domain层里。而这些层，是纯粹的、不依赖任何 Web 细节的 Rust 代码。因此，它们可以被进行最纯粹、最快速的单元测试。

单元测试一个 Hyperlane 服务：速度与激情的体验 ⚡️

让我们想象一个UserService，它负责处理用户注册的逻辑。按照 Hyperlane 的架构建议，它可能长这样：

// in src/app/service/user_service.rs// UserService依赖于一个trait（接口），而不是一个具体的数据库实现
pub struct UserService {pub user_repo: Arc<dyn UserRepository>,
}impl UserService {pub fn register_user(&self, username: &str) -> Result<User, Error> {// 核心逻辑：检查用户名是否存在if self.user_repo.find_by_username(username).is_some() {return Err(Error::UsernameExists);}// ... 其他逻辑，比如检查密码强度等 ...let user = User::new(username);self.user_repo.save(&user)?;Ok(user)}
}

现在，我们要如何测试register_user这个函数呢？我们不需要启动服务器，也不需要连接真实的数据库。我们只需要测试这段逻辑本身。我们可以使用一个“测试替身”（Test Double），通常是一个“模拟对象”（Mock Object），来扮演UserRepository的角色。

在 Rust 中，我们可以用mockall这样的库来轻松地创建模拟对象。

// in tests/user_service_test.rs#[cfg(test)]
mod tests {use super::*;use mockall::*;// 创建一个UserRepository的模拟实现#[automock]trait UserRepository {fn find_by_username(&self, username: &str) -> Option<User>;fn save(&self, user: &User) -> Result<(), DbError>;}#[test]fn test_register_user_fails_if_username_exists() {// 1. 准备：创建一个模拟的repositorylet mut mock_repo = MockUserRepository::new();// 2. 设定预期：我们期望`find_by_username`这个方法//    会被以"testuser"为参数调用一次，//    并且当它被调用时，应该返回一个存在的用户。mock_repo.expect_find_by_username().with(predicate::eq("testuser")).times(1).returning(|_| Some(User::new("testuser")));// 把模拟对象注入到我们的service中let user_service = UserService { user_repo: Arc::new(mock_repo) };// 3. 执行：调用我们想测试的函数let result = user_service.register_user("testuser");// 4. 断言：我们期望结果是一个“用户名已存在”的错误assert!(matches!(result, Err(Error::UsernameExists)));}
}

请仔细品味这段测试代码。它美在哪里？

快：它运行在内存中，不涉及任何 I/O。执行它只需要几毫秒，甚至更短。你可以拥有成千上万个这样的测试，并在几秒钟内得到反馈。
准：它精确地测试了我们关心的业务逻辑——“当用户名存在时，注册应该失败”。它不受任何外部因素的干扰。
强：我们可以轻松地模拟各种边界情况。数据库连接失败？让mock_repo.expect_save()返回一个Err(DbError::ConnectionFailed)就行了。这种控制力，是端到端测试无法比拟的。

那`controller`怎么办？

当然，我们依然需要少量的集成测试，来确保controller层的路由被正确地绑定到了service层的方法上，以及 JSON 的序列化和反序列化是正常的。但因为所有的复杂逻辑都已经在service层被单元测试覆盖了，所以controller的测试可以非常简单，通常只需要覆盖“成功路径”即可。这些测试的数量会远远少于单元测试。