XCTest断言用于把测试期望写成可执行检查。Jon Reid的《iOS Unit Testing by Example》2020年第一版讨论了快速反馈和独立练习空间；本文沿用这些入门主题，补充简短示例，并区分书中模板背景与项目实际配置。
及时、稳定且能定位问题的反馈有助于重构。下面以XCTest自身的断言为练习对象；测试通过只说明已执行的断言没有报告失败，不代表业务测试已经充分。
一、先建个“测试实验区”：摸清断言的脾气
出版社公开的第一章摘录介绍了独立实验项目，让读者观察断言如何成功和失败。这里采用同样的练习思路，不把练习环境设置当作所有iOS项目必须遵循的规范。
动手建实验项目
在现有或新建Swift项目中配置XCTest单元测试目标，确认测试文件属于正确目标。2020年书中练习选择Storyboard，是当时示例的界面配置，并非XCTest禁止使用SwiftUI。不同Xcode版本的模板与入口可能不同，按实际版本确认；若模板使用其他测试框架，应区分其语法与下面的XCTestCase示例。
为练习新建独立测试文件或目标，保留原项目已有测试。在XCTestCase子类中写以test开头、无参数的测试方法，选择合适的运行目标，再执行测试并查看结果。空测试集没有失败，不表示已经验证任何业务行为。
二、断言不是摆设：它是测试的“期望值标尺”
断言陈述预期：XCTAssertEqual检查相等，XCTAssertNotNil检查可选值存在；浮点运算通常需要按业务精度使用容差。断言失败时，应结合输入、期望、实际结果和失败行定位问题。
例如，重构接口参数拼接时，可用固定输入断言生成的请求参数，快速发现行为变化。这里是测试思路示例，不是已发生的个人经历或节省工时统计。
三、从实验到实战：断言怎么融入日常开发？
一个测试通常围绕一个可命名的行为或场景组织，断言数量不是硬性规则。同一结果对象的多个相关字段可以一起检查；相互独立的失败原因则适合拆开。异步行为应等待完成并检查结果，不能在请求尚未返回时就结束测试。
对订单金额，可按无优惠、单项优惠和税费规则分别设计场景。一个场景中检查金额与对应明细并不违规；重点是预期是否独立可信、失败是否容易解释。
做好iOS单元测试断言，其实是给代码加层“安全网”。按里德的方法，先在实验区摸透XCTest的细微处，再慢慢把断言融进日常开发——你会发现，重构不再怕改崩，代码质量也跟着往上走。
从最小示例观察失败反馈，再将真实输入域、错误处理和依赖隔离逐步纳入项目测试。避免把框架入门练习当作完整业务验收。
最小断言练习
将以下代码放入XCTest测试目标的独立Swift文件，观察三个测试的结果。把第一个期望值从5改为6，应出现断言失败；恢复为5后重新运行。浮点容差1e-12只用于此处演示，实际精度需由业务定义。
import XCTest
final class AssertionExamplesTests: XCTestCase {
func test_integerAddition() {
let actual = 2 + 3
XCTAssertEqual(actual, 5, "应等于整数相加的结果")
}
func test_optionalValueExists() {
let value: String? = "ready"
XCTAssertNotNil(value)
}
func test_floatingPointComparison() {
let actual = 0.1 + 0.2
XCTAssertEqual(actual, 0.3, accuracy: 1e-12)
}
}
这些练习分别展示相等、非空与容差语法，不验证任何真实订单或网络功能。项目测试还需要针对其实现和业务规则补充输入、异常与可重复性检查。
资料：Apple XCTest文档；出版社书籍介绍及第一章公开摘录（2020年）。书中界面和模板步骤应结合实际Xcode版本使用。
