0x03 单元测试与Junit单元测试是软件开发中**最基础**的测试环节。它的核心目标是验证代码中**最小的可测试单元

一、背景

单元测试是软件开发中最基础的测试环节。它的核心目标是验证代码中最小的可测试单元（通常是一个函数或方法）是否按照预期工作。最近在开发中愈发觉得单元测试的重要性，于是简单了解了单元测试的基本概念和原理，这里简单分享一下。

二、什么是单元测试

单元测试（Unit Testing） 是对软件中最小的可测试部分（通常是一个类、一个方法或一个函数）进行验证的自动化检查过程。

我们可以把构建一个复杂的 Android 应用想象成盖一栋摩天大楼。在砌墙之前，我们需要确保每一块砖头都是坚固且符合规格的。如果砖头内部有裂痕，即便建筑图纸再完美，大楼最终也会倒塌。单元测试，就是那个在出厂前对每一块“代码砖头”进行严苛质检的过程。

一个优秀的单元测试应该具备以下三个核心特征：

原子性：它只验证一段极其微小的逻辑。如果测试失败，开发者能立刻定位到是哪几行代码出了问题，而不需要在成百上千行代码中排查。
独立性：测试用例之间不能相互干扰，且不应该依赖外部的真实环境（如真实的数据库、网络请求或文件系统）。
自动化：单元测试应该是可以通过命令行或 IDE 一键运行的，并在几秒钟内执行成千上万次，给出明确的“通过”或“失败”结果。

三、如何进行单元测试

掌握了单元测试的概念后，我们需要一套标准的方法论来将其实践到日常开发中。

核心法则：AAA 模式

在编写具体的测试用例时，业界公认的最佳实践是 AAA 模式，它能让你的测试代码像说明书一样清晰易懂：

Arrange（准备） ：这是初始化阶段。你需要搭建好测试所需的上下文环境，比如创建目标对象、准备好输入的数据或配置好依赖项。
Act（执行） ：这是触发阶段。在这个环节，你只需要调用那个你需要测试的目标方法。
Assert（断言） ：这是验证阶段。你需要检查目标方法的返回值，或者它产生的副作用是否完全符合你的预期。

隔离外部干扰：Mock（模拟）技术

在实际开发中，我们的函数很少是孤立的。比如一个“用户登录”函数，它可能需要去读取本地的 SharedPreferences，或者向服务器发送一个网络请求。为了保持单元测试的“独立性”和“运行速度”，我们不能真的去发起网络请求。这时就需要用到 Mock 技术（如 Mockito 框架）。我们可以制造一个“假”的网络请求对象，强制让它返回成功或失败的数据，从而专注于测试“登录函数”在面对这些数据时的逻辑处理。

进阶理念：测试驱动开发 (TDD)

除了在写完代码后补充测试，还有一种更为极致的开发方式叫做 TDD（测试驱动开发） 。它的核心逻辑是颠倒传统的开发顺序：先写测试，后写业务代码。

它的循环被称为“红-绿-重构”：

红灯 🔴：先写一个测试用例。因为业务代码还没写，所以这个测试一定会失败（飘红）。
绿灯 🟢：编写最少量的、刚刚好能让这个测试通过的业务逻辑。
重构 🔵：在测试用例的保护下，安心地优化代码的结构和可读性。

这种方式能强制开发者从使用者的角度去设计 API，写出来的代码天然具备高可测试性和低耦合度。

四、JUnit 介绍

了解了如何测试，我们需要一个引擎来运行这些测试。在 Java 和 Android 的生态圈中，JUnit 是绝对的标准和霸主。它是一个开源的单元测试框架，为我们提供了定义测试、运行测试以及判断结果的工具。

JUnit 的核心组件

JUnit 的语法非常简洁，主要依赖于注解（Annotations）和断言（Assertions）：

生命周期注解：用来控制测试环境的搭建与销毁。
- @Test：最核心的注解，只要在一个普通的方法上加上它，JUnit 就会把这个方法当成一个独立的测试用例来运行。
- @Before：被它标记的方法，会在每一个 @Test 方法执行前自动运行。非常适合用来做 Arrange（准备）阶段的重复性工作，比如重置对象状态。
- @After：在每一个测试方法执行后运行，通常用于清理内存、关闭流等扫尾工作。
断言库（Assertions） ：用来执行 AAA 模式中的最后一步。例如 assertEquals(expected, actual) 用于判断两个值是否相等，assertTrue(condition) 用于判断逻辑真假。

Android 环境下的 JUnit 实战

假设我们编写了一个电商应用中的 DiscountCalculator（折扣计算器）类，规则是“订单金额超过 100 元即可享受九折优惠”。

在 Android Studio 中，我们通常将此类纯逻辑测试放在 src/test/java/ 目录下，并使用 JUnit 编写如下代码：

Kotlin

import org.junit.Assert.assertEquals
import org.junit.Before
import org.junit.Test

class DiscountCalculatorTest {

    private lateinit var calculator: DiscountCalculator

    @Before
    fun setUp() {
        // 在每个测试开始前，初始化计算器
        calculator = DiscountCalculator()
    }

    @Test
    fun calculate_amountOver100_returnsTenPercentOff() {
        // Arrange (准备): 金额为 200，预期打九折后是 180
        val amount = 200.0
        val expected = 180.0
        
        // Act (执行)
        val actual = calculator.calculate(amount)
        
        // Assert (断言): 比较预期值和实际值，0.001 为浮点数允许的误差
        assertEquals(expected, actual, 0.001) 
    }

    @Test
    fun calculate_amountExactly100_noDiscount() {
        // 测试边界条件：正好 100 元时不打折
        val actual = calculator.calculate(100.0)
        assertEquals(100.0, actual, 0.001)
    }
}

通过 Android Studio 界面左侧的绿色箭头，或者在终端执行 ./gradlew test 命令，JUnit 就会自动扫描这些注解，秒级反馈测试报告。

五、结语

单元测试不仅是捕捉 Bug 的“第一道防线”，更是代码质量的“安全网”。在如今 AI 辅助编程普及的时代，单元测试的地位反而更加不可替代：

AI 擅长生成代码，但它并不总能保证逻辑的绝对正确。 在 AI 编码环境下，开发者的核心职责正从“亲自写代码”转向“评审与验证代码”。完善的单元测试就是验证 AI 生成内容是否靠谱的最佳手段。只有当我们拥有了自动化测试的能力，才能真正释放 AI 的生产力，实现既快速又稳定的高质量交付。

0x03 单元测试与Junit

一、 背景