BDD在Swift中：编写业务能理解的测试

为什么普通测试不够用，以及什么是BDD

每位iOS开发者都遇到过这种情况：你写了一百个单元测试，覆盖率达到90%，但在下一次演示时，经理却说：“为什么点击这个按钮时什么也没发生？”你查看代码——一切正常。问题在于，单元测试检查的是代码，而不是系统的行为。这时BDD（行为驱动开发）就派上了用场——这是一种消除“技术性”测试与“业务逻辑”之间界限的方法论。

Swift中的BDD不仅仅是一个时髦的术语。它是一种编写测试的方式，使得不仅开发者能读懂，分析师、测试人员甚至客户也能理解。在本文中，我们将探讨如何使用Quick和Nimble框架将行为驱动开发引入你的iOS项目，并展示Swift中的实际示例。

用简单的话说什么是BDD

想象一下，你写的不是测试，而是一个电影剧本。剧本中有角色（用户、系统）、事件（点击按钮、发送请求）和预期结果（弹出提示、更新UI）。BDD就是这样一个“剧本”，只不过是为你的应用而写。

核心理念是：测试应该从用户的角度描述系统的行为。与其写“方法saveUser()返回true”，不如写“当用户输入有效的电子邮件并点击‘保存’时，系统显示‘成功’消息”。

BDD与TDD的区别

很多人将BDD与TDD（测试驱动开发）混淆。区别很简单：

• TDD——先写测试，再写代码，然后重构。重点在于实现的正确性。
• BDD——先写行为场景，再写实现该行为的代码。重点在于对用户的价值。

BDD是TDD的演进。如果说TDD回答的是“代码是否正确工作？”，那么BDD回答的是“代码是否做了业务需要的事情？”。

Swift中BDD的工具

在Swift世界中，行为驱动开发有两个主要“支柱”：

• Quick——用于以BDD风格编写测试的框架。它替代了标准的XCTest，并提供了describe/context/it语法。
• Nimble——用于“匹配器”（断言）的库。你不再写XCTAssertEqual，而是写expect(value).to(equal(5))——这读起来像一个英文句子。

这些工具配合得很好，让你能编写看起来像规范说明的测试。

通过Swift Package Manager安装Quick和Nimble

在你的Package.swift或通过Xcode添加依赖：File → Add Packages → 输入Quick仓库的URL：https://github.com/Quick/Quick.git和Nimble的URL：https://github.com/Quick/Nimble.git。

Package.swift的示例：

// swift-tools-version:5.9import PackageDescription

let package = Package(    name: "MyApp",    dependencies: [        .package(url: "https://github.com/Quick/Quick.git", from: "7.0.0"),        .package(url: "https://github.com/Quick/Nimble.git", from: "13.0.0"),    ],    targets: [        .target(name: "MyApp"),        .testTarget(            name: "MyAppTests",            dependencies: ["MyApp", "Quick", "Nimble"]        )    ])

编写第一个Swift BDD测试

假设我们有一个简单的LoginService，用于验证用户名和密码。与其编写枯燥的XCTest，不如创建一个BDD风格的测试。

服务代码（供上下文参考）

class LoginService {    func authenticate(username: String, password: String) -> Result<User, LoginError> {        guard !username.isEmpty else { return .failure(.emptyUsername) }        guard !password.isEmpty else { return .failure(.emptyPassword) }        guard pas