TDD：它是什么、测试原则和方法论

什么是 TDD？

Test-Driven Development — 是一种软件开发实践，其中自动化测试决定生产代码的编写。与传统方法（先编写代码，然后测试）不同，TDD 颠倒了顺序：先编写测试，然后编写通过此测试的代码。

TDD 的奠基人是 Kent Beck，他在 20 世纪 90 年代末在 Extreme Programming (XP) 方法论的框架内阐述了这一实践。在 “Test-Driven Development: By Example” (2002) 一书中，Beck 描述了 TDD 的五条成为经典的规则：在生产代码之前编写测试，编写恰好足够通过测试的代码，以及在每个循环之后进行重构。

TDD 的关键原则

第一个原则 — 测试定义接口。开发人员在考虑组件如何实现之前被迫考虑组件将如何使用。这从一开始就形成了干净的 API。

TDD 作为设计技术

第二个原则 — 最小化实现。当测试编写完成后，开发人员编写恰好足够通过测试的生产代码——不多写一行。这可以防止过早的抽象和过度复杂化，Martin Fowler 称之为 Speculative Generality。

TDD 与普通测试的区别

TDD 与 “事后” 测试之间的关键区别 — 顺序的纪律。在 TDD 中，测试不仅检查代码——它还引导其结构。根据 Microsoft Research (Nagappan et al., 2008) 的研究，应用 TDD 的团队与传统方法的团队相比，缺陷密度降低了 40–90%。

Red-Green-Refactor 循环

Red-Green-Refactor 循环 — 是为每个新测试重复的三步序列。Red：编写一个不通过的测试。Green：编写最少的代码使测试通过。Refactor：在不改变其行为的情况下改进代码。

Red 阶段：编写失败的测试

开发人员编写一个检查尚未实现功能的测试。在这个阶段，测试应该 失败——这确认了测试确实在检查某些东西。在 Android 开发环境中，JUnit 5 框架为失败的测试显示红色指示，这为该阶段命名。

class CalculatorTest {
    fun testAddition() {
        val result = Calculator().add(2, 3)
        Assertions.assertEquals(5, result)
    }
}

Green 阶段：最小化实现

在这个阶段，编写足够通过测试的最少生产代码。没有冗余——只有绿色指示所需的内容。如果实现可以是常量——那就让它成为常量。重构将在下一步进行，当新测试出现时。

class Calculator {
    fun add(a: Int, b: Int): Int {
        return a + b
    }
}

Refactor 阶段：无风险改进

绿色测试是 重构 的保障。开发人员可以重写实现、优化性能或改进可读性，确信测试将立即检测到与预期行为的任何偏差。在 Android 移动开发中，这个阶段对于提取公共接口和减少代码重复尤为重要。

TDD 在移动开发中的优势

在移动项目中应用 TDD 可带来可衡量的优势，这些优势得到了学术研究和领先开发工作室实践的证实。

降低缺陷密度

IBM (Bhat & Nagappan, 2006) 对四个工业项目的研究表明，使用 TDD 的团队与类似传统工作的团队相比，缺陷减少了 40%。对于移动开发，在 Google Play 发布后修复错误的成本远高于代码编写阶段，这一指标至关重要。

通过测试记录代码

按 TDD 编写的测试充当 API 的 活文档。进入项目的开发人员可以阅读测试并了解每个组件应该如何被使用。在团队高流动性的情况下——移动工作室的典型问题——这尤其有价值。

自信的重构

超过 90% 的测试覆盖代码使开发人员能够进行重构而不用担心破坏任何东西。Google 在 “Software Engineering at Google” (2020) 一书中将测试覆盖称为关键因素，它使得在拥有数百万行代码的项目中保持代码库整洁成为可能。

TDD 的工具和框架

移动开发中的 TDD 生态系统包括用于单元测试、模拟和 UI 组件检查的工具——既适用于 Android，也适用于 iOS。

为 Android 选择框架

对于 Kotlin 上的 Android 项目，标准堆栈包括 JUnit 5 + MockK。MockK 优于 Mockito，因为它支持 Kotlin 的一级函数——密封类、协程和挂起函数，无需额外配置。

iOS 工具

在 iOS 开发中，TDD 通过 XCTest 实现——Apple 的内置框架，提供断言、测试类以及通过 Xcode Server 或 GitHub Actions 与 CI/CD 的集成。iOS 上的模拟使用 Cuckoo 和 OHHTTPStubs 库。

Kotlin 中的 TDD 代码示例

让我们看看 Android 上 Kotlin 中一个真实的 TDD 场景——测试用户仓库。首先编写测试，然后——通过此测试的实现。

步骤 1：UserRepository 的测试

class UserRepositoryTest {
    private val api = mockk<UserApi>()
    private val dao = mockk<UserDao>()
    private val repo = UserRepository(api, dao)

    fun `when api returns user then cache and emit`() = runTest {
        val user = User(1, "Alice")
        coEvery { api.getUser(1) } returns user
        every { dao.insert(user) } returns Unit

        val result = repo.getUser(1)

        assertEquals(user, result)
        verify { dao.insert(user) }
    }
}

步骤 2：最小化实现

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUser(id: Int): User {
        val user = api.getUser(id)
        dao.insert(user)
        return user
    }
}

步骤 3：带有离线模式的缓存测试

通过第一个测试后，我们添加第二个——检查 网络错误 时的行为。现在测试规定，当 API 失败时，仓库应从缓存返回数据。

fun `when api fails then return cached user`() = runTest {
    val cached = User(1, "Cached Alice")
    coEvery { api.getUser(1) } throws IOException()
    every { dao.getById(1) } returns cached

    val result = repo.getUser(1)

    assertEquals(cached, result)
}

实施 TDD 时的常见错误

过渡到 TDD 伴随着典型错误，这些错误可能会使方法论的所有优势都付诸东流。理解这些陷阱有助于团队更有效地实施该实践。

测试太大

第一个也是最常见的反模式 — 在一个测试中 测试过多的功能。测试应该只检查一个断言。如果测试失败，开发人员应该知道确切是哪里出了问题，而无需额外的调试。

忽略红色阶段

第二个错误 — 编写一开始就通过的测试。如果测试从未至少变红一次，就没有信心它确实在检查任何东西。规则：永远不要相信你从未见过失败的测试。

跳过重构

第三个典型错误 — 停留在绿色阶段。重构 不是可选的，而是循环的强制阶段。没有它，代码库会退化，测试变得脆弱，TDD 的优势也会丧失。

• 测试实现而非行为 — 测试绑定到细节，在每次重构时都会断裂
• 缺少边缘情况的测试 — 空列表、null 值、边界条件未被覆盖
• 忽视测试速度 — 慢速测试会减慢反馈循环并扼杀 TDD 纪律