一、理解为什么要测试
本单元学习目标：解释为什么测试很重要（数学、设计、集体的好处）；说明 Apex 单元测试的要求；理解代码覆盖率以及如何提升它。这些基础将指导你写出的每一个测试。
为什么要测试：数学、设计与集体
数学（数字不会说谎）：一个未测试的 if 分支 = 2 条未测试路径；10 个分支 = 1024 条可能路径；100 个分支 = 比宇宙原子还多的路径。你无法手动验证每条路径，测试能在规模上自动验证。
IBM 在 2010 年关于修复 bug 相对成本的研究结论很清晰：设计阶段发现的 bug，修复成本是 1 小时；实现（开发）阶段是 6.5 小时；功能测试阶段跳升到 15 小时；而到了生产环境，修复成本飙升至 100 小时。bug 越早修复越便宜。
设计（能用不够）：今天能用的代码明天可能就坏。每次改动都引入风险，测试在生产前捕获回归。测试不是证明代码能用，而是证明代码在系统演化中持续能用。
集体测试（相互成就）：团队每个人都写测试，整个代码库受保护。你的测试保护我的改动，我的测试保护你的改动。测试共同构成安全网，让重构和快速迭代有了信心。测试 = 规模化的风险管理。
再次强调：为什么要测试
测试不是：部署的复选框、最后才做的事、可选的最佳实践。测试是：代码按设计工作的证据、对未来改动破坏的保护、预期行为的文档、重构和改进的信心、平台强制的要求（75% 覆盖率）。
每一行未测试的代码都是负债；每个测试都是持续分红的资产。测试是一种投资，不是成本。尽早测试、经常测试、测试一切。
二、确定该测试什么
第二单元学习 Apex 单元测试的具体要求：必须测试什么、代码覆盖率要求，以及提升覆盖率的策略。
Apex 单元测试与代码覆盖率
Apex 单元测试：@isTest 注解类和方法的 static 测试方法；测试在隔离中运行（无 org 数据）；Test.startTest()/Test.stopTest() 隔离 governor limits；System.assert() 方法校验结果。
代码覆盖率要求：生产部署最低 75%，计算方式为（覆盖行数 ÷ 总行数）× 100，覆盖整个 org 的所有 Apex 代码（触发器也计入），每次部署都会校验覆盖率。75% 是最低要求，目标是 90%+ —— 更高的覆盖率让你对未覆盖的那 10% 不是关键路径更有信心。
提升你的代码覆盖率
达到并超过 75% 的策略：测正向用例（合法输入、预期输出）、负向用例（非法输入、预期错误）、批量场景（200 条而非 1 条）、所有分支（每个 if/else、每个 switch）、边界用例（null、空、边界值）、触发器的 insert/update/delete/undelete 全部操作。
其他考量：测试数据真实但最小化、用 Test.startTest/stopTest 获得全新 limits、用 HttpCalloutMock mock 外部 callout、测试保持隔离（不依赖其他测试）、部署前跑所有测试、立即修复失败测试（别让它们累积）。
覆盖率是度量而非目标——真正的目标是「代码能工作」的信心，覆盖率只是彻底测试的副产品。