什么是单元测试？

什么是单元测试？

单元测试是一种软件测试方法， 代码的单个单元或组件（例如函数、方法或类）会进行独立测试，以验证其是否正常工作。目标是验证应用程序的最小组件是否在不依赖外部系统的情况下按预期运行。

A 单元 可以小到单个函数，也可以大到一个小模块，这取决于软件的设计方式。关键原则是 隔离：应该模拟或存根数据库、API 或文件系统等外部资源，以便测试仅关注单元的逻辑。

例如，在 Python:

def add (a, b): 
return a + b 
def test_add():
assert add(2, 3) == 5

这个简单的测试检查 add 函数返回正确的结果。虽然很简单，但它体现了这样一种理念：在与系统其他部分集成之前，应该先独立验证逻辑。

通过进行单元测试，开发人员可以创建一个 安全网 可以快速检测回归、支持重构并提高软件可维护性。

单元测试视频讲解

为什么要进行单元测试？

单元测试 这一点很重要，因为软件开发人员有时会尝试通过进行最少的单元测试来节省时间，但这是一个误区，因为不适当的单元测试会导致在开发过程中修复缺陷的成本很高。 系统测试, 集成测试， 甚至在应用程序构建完成后进行 Beta 测试。如果在开发早期就进行适当的单元测试，最终可以节省时间和金钱。

以下是在软件工程中进行单元测试的主要原因：

• 早期错误检测 – 问题出现在靠近其产生地点的地方，使得修复更快、更便宜。
• 提高代码质量 – 干净、可测试的代码通常会带来更好的架构和更少的隐藏依赖关系。
• 回归保护 – 单元测试在重构期间充当安全网，确保旧功能继续发挥作用。
• 更快的开发周期 – 自动化测试缩短了 QA 反馈循环并减少了手动测试开销。
• 更高的团队信心 – 凭借强大的单元测试覆盖，开发人员可以部署更新，并且知道更新不会破坏现有功能。

总之： 单元测试可以节省时间、降低风险并提高可靠性它将测试从痛苦的事后想法转变为主动的工程实践。

如何执行单元测试？

可靠的单元测试流程应具有可预测性、快速性和自动化的特点。使用这六步循环，可以确保高质量并快速获得反馈。

步骤 1）分析单元并定义案例

确定最小的可测试行为。列出 快乐之路, 边缘情况和 错误条件. 明确输入/输出和前提/后置条件。

步骤2）设置测试环境

选择框架，加载最少的装置，然后 隔离依赖关系 （模拟/存根/伪造）。保持设置轻量级，以避免缓慢而脆弱的测试。

步骤3）编写测试（AAA模式）

排列 输入和上下文 → 法案 通过调用单位→ 断言 预期结果。优先考虑行为断言，而非内部实现细节。

# Arrange
cart = Cart(tax_rate=0.1)
# Act
total = cart.total([Item("book", 100)])
# Assert
assert total == 110

步骤 4）在本地和 CI 中运行

首先在您的机器上执行测试；然后在 CI 中运行以检查干净的环境。快速失败；保持日志简洁且可操作。

步骤5）诊断故障、修复和重构

当测试失败时， 修复代码或测试，而不是同时进行。绿色完成后，放心地进行重构——测试保护行为。

步骤6）重新运行， Rev查看并维护

重新运行完整套件。删除不稳定的测试，删除重复的fixture，并强制执行 覆盖阈值 不要玩弄它们。标记运行速度慢的测试，以减少运行频率。

专业提示：

• 保持测试 来迅速 （每个<200毫秒）和 独立.
• 名称测试 行为 （例如， test_total_includes_tax).
• 将不稳定视为错误；隔离，修复根本原因，然后重新启用。

有哪些不同的单元测试技术？

单元测试在混合时最有效 智能测试设计技术 - 合理的覆盖目标在重要的地方追求广度，在风险最高的地方追求深度，并抵制“100% 或破产”的陷阱。

这个 单元测试技术 主要分为三部分：

1. 黑匣子测试 涉及用户界面以及输入和输出的测试
2. 白盒测试 涉及测试软件应用程序的功能行为
3. 灰盒测试 用于执行测试套件、测试方法和测试用例，并进行风险分析

覆盖范围是 领先指标而不是终点线。用它来 寻找盲点，而不是玩弄数字。单元测试中使用的代码覆盖率技术如下：

• 声明覆盖范围
• 决策覆盖
• 分支机构覆盖范围
• 条件覆盖
• 有限状态机覆盖

有关代码覆盖率的更多信息，请参阅 https://www.guru99.com/code-coverage.html

单元测试中模拟和存根的作用是什么

单元测试应该只关注被测代码—— 不是它的依赖项。 那是在哪里 嘲笑 和 存根 进来。这些“测试替身”取代了真实的对象，这样你就可以隔离行为、控制输入，并避免缓慢或不稳定的测试。

为什么要使用测试 Doubles?

• 隔离度 – 仅测试单元，而不是数据库、网络或文件系统。
• 确定性 – 控制输出和副作用，以使结果保持一致。
• 速度 – 当测试不接触外部系统时，测试可以在几毫秒内运行。
• 边缘情况模拟 – 轻松模拟错误（例如 API 超时），而无需在现实生活中等待它们。

存根

A 存根 是一个简化的替代方案，返回固定的响应。它不记录交互，只提供预设数据。

例子 （Python):

def get_user_from_db(user_id):
# Imagine a real DB call here
raise NotImplementedError()
def test_returns_user_with_stub(monkeypatch):
# Arrange: stubbed DB call
monkeypatch.setattr("app.get_user_from_db", lambda _: {"id": 1, "name": "Alice"})
# Act
user = get_user_from_db(1)
# Assert
assert user["name"] == "Alice"

嘲弄

A 嘲笑 更强大：它可以验证交互（例如，“此方法是否用 X 调用？”）。

例子 （Java使用 Jest 编写脚本):

const sendEmail = jest.fn();
function registerUser(user, emailService) {
emailService(user.email, "Welcome!");
test("sends welcome email", () => {
// Arrange
const user = { email: "test@example.com" };
// Act
registerUser(user, sendEmail);
// Assert
expect(sendEmail).toHaveBeenCalledWith("test@example.com", "Welcome!");

});

在这里， 嘲笑 检查电子邮件服务是否被正确调用 — — 这是存根无法做到的。

常见的陷阱

• 过度嘲笑 – 如果每个合作者都被嘲笑，测试就会变得脆弱并与实施细节紧密相关。
• 测试模拟而不是行为 – 尽可能关注结果（状态/返回值）而不是互动。
• 泄漏设置代码 – 保持模拟/存根轻量；使用助手或固定装置以提高可读性。

经验法则

• 当你只需要数据时，使用存根.
• 当你需要验证交互时进行模拟.
• 更喜欢假货而不是沉重的模拟 当你可以的时候（例如，使用内存数据库而不是模拟每个查询）。

底线： 模拟和存根 配角，而不是星星。用它们来隔离你的单元，但不要让它们劫持测试套件。

有哪些常见的单元测试工具？

有几种自动化单元测试软件可用于协助软件测试中的单元测试。我们将在下面提供几个示例：

1. JUnit：Junit 是一款免费使用的测试工具，用于 Java 编程语言。它提供断言来识别测试方法。此工具首先测试数据，然后将其插入到代码片段中。
2. NUnit：NUnit 是一个广泛用于所有 .NET 语言的单元测试框架。它是一个开源工具，允许手动编写脚本。它支持数据驱动的测试，并且可以并行运行。
3. PHPUnitPHPUnit 是一款面向 PHP 程序员的单元测试工具。它提取一小部分代码（称为单元），并分别进行测试。该工具还允许开发人员使用预定义的断言方法来断言系统是否以某种方式运行。

这些只是可用的单元测试工具中的一小部分。还有很多，尤其是 C 语言 和 Java，但无论您使用哪种语言，您一定能找到适合您编程需求的单元测试工具。

测试驱动开发 (TDD) 和单元测试

TDD 中的单元测试广泛使用测试框架。单元测试框架用于创建自动化单元测试。单元测试框架并非 TDD 独有，但却至关重要。下面，我们来看看 TDD 为单元测试领域带来的一些变化：

• 测试在代码之前编写
• 严重依赖测试框架
• 应用程序中的所有类都经过测试
• 实现快速简便的集成

以下是 TDD 的一些好处：

• 鼓励小型、可测试的单元和简单的设计。
• 防止过度设计；只构建测试所需的内容。
• 为重构提供了一个活生生的安全网。

专家建议: 根据需要选择 TDD 严格的设计反馈 在代码级别和单元上快速、渐进地进步。

为什么要将单元测试集成到 CI/CD 中？

当单元测试直接连接到 持续集成和持续交付 (CI/CD) 管道。它们不再是事后才想到的，而是 质量门 在发货前自动验证每个更改。

以下是将单元测试集成到 CI/CD 管道的原因：

• 立即反馈 – 开发人员在几分钟内就能知道他们的更改是否破坏了某些东西。
• Shift-剩余质量 – 在提交时发现错误，而不是在发布后。
• 对部署的信心 – 自动检查确保“绿色构建”可以安全推送。
• 可扩展协作 – 任何规模的团队都可以合并代码而不会互相干扰。

单元测试的神话

以下是关于单元测试的一些常见误区：

“这需要时间，而我的日程总是排得满满的。我的代码非常稳定！我不需要单元测试。”

神话本质上是错误的假设。这些假设会导致以下恶性循环：

事实是，单元测试提高了开发速度。

程序员认为集成测试会捕获所有错误，而不会执行单元测试。然而，一旦单元集成完成，一些原本可以在单元测试中轻松发现和修复的简单错误，却需要花费很长时间才能追踪和修复。

单元测试优势

• 想要了解单元提供哪些功能以及如何使用这些功能的开发人员可以查看单元测试以获得对单元 API 的基本了解。
• 单元测试允许程序员在以后重构代码并确保模块仍然正常工作（即 回归测试）该程序是为所有功能和方法编写测试用例，以便每当更改导致故障时，都可以快速识别和修复。
• 由于单元测试的模块化特性，我们可以测试项目的各个部分，而无需等待其他部分完成。

单元测试的缺点

• 单元测试不可能捕获程序中的所有错误。即使是最简单的程序，也不可能评估所有执行路径。
• 单元测试本质上关注的是代码单元。因此，它无法捕获集成错误或广泛的系统级错误。

建议将单元测试与其他测试活动结合使用。

单元测试最佳实践

• 单元测试用例应相互独立。如果需求有任何增强或变更，单元测试用例不应受到影响。
• 每次只测试一个代码。
• 遵循清晰、一致的单元测试命名约定
• 如果任何模块的代码发生变化，请确保有相应的单元 测试用例 对于模块，并且模块在更改实现之前通过了测试
• 在进入 SDLC 的下一阶段之前，必须修复单元测试期间发现的错误
• 采用“测试即代码”的方法。未经测试的代码越多，需要检查错误的路径就越多。

常见问题

结语