揭秘 Apex 测试类：一个实践者的视角

二月 04, 2026

当我第一次接触 Salesforce 开发，或者说真正开始写 Apex 代码时，最先被告知的硬性要求，就是那条经典的“至少 75% 的代码覆盖率”。这个数字像一道门槛，横在我面前。它一开始在我看来，更像是一种合规性要求，而非真正意义上的质量保证。然而，随着项目经验的积累，我对 Apex 测试类的理解也逐渐深入，从最初的“如何达标”过渡到了“如何写出真正有用的测试”。

初期困惑：`@isTest(seeAllData=true)` 的诱惑与陷阱

最初为了快速达到覆盖率，我曾‘不假思索’地使用了 @isTest(seeAllData=true) 这个注解。坦白说，当时的我只是觉得这样方便，省去了创建测试数据的麻烦，直接就能访问到组织中的所有数据，快速覆盖到业务逻辑。特别是在一些涉及少量配置数据或者标准对象操作的场景下，这似乎是个快捷的选项。

为什么它很“方便”？

省去了数据准备：不用写代码创建测试数据，直接用现有的。
快速验证：对于一些简单逻辑，能够快速跑通测试。

为什么我很快就放弃了它？

这种“方便”很快就演变成了各种问题。我发现测试用例变得非常脆弱，测试环境的不确定性，随时可能因为生产数据变动而导致测试失败，更别提部署到沙盒时可能遇到的各种数据差异了。比如，如果某个测试依赖于一条特定名称的账户记录，而这条记录在另一个环境被删除了或者名称改变了，测试就会无缘无故地失败。这根本不是测试应该有的行为，测试的目的是验证代码逻辑，而不是验证数据存在。

我很快意识到这种做法的危害，并决心摒弃它。我当时的判断是：测试应当是独立、可重复的，不依赖外部环境的。一个好的测试应该能够随时随地、在任何环境下运行，并给出一致的结果。依赖全局数据使得测试变得不可预测，大大增加了维护成本和调试难度。

告别重复：拥抱 `@testSetup` 的高效

当放弃 seeAllData=true 后，下一个自然而然的问题就是：“我的测试数据从哪来？”

手动创建数据的痛点

最直接的方式就是在每个测试方法中手动创建所需的数据。比如，我的一个测试方法需要一个账户和两个联系人，我就在测试方法里创建它们。另一个测试方法可能也需要类似的数据，于是我又重新创建一遍。

代码重复：大量用于创建测试数据的代码被复制粘贴到各个测试方法中。
维护困难：如果数据结构有变化，需要修改所有相关测试方法。
运行时间：每次测试方法都从头创建数据，导致测试运行时间越来越长，尤其是在测试类数量增多时。

`@testSetup` 的出现简直是救星

在了解了 @testSetup 注解后，我立刻看到了它的价值。我的理解是：它允许我在测试类中定义一个单独的方法，在这个方法中创建所有测试用例所需的公共测试数据。这个方法只在测试类执行前运行一次，为所有测试方法提供一份“干净”且隔离的共享数据。


@isTest
private class MyServiceTest {

    @testSetup
    static void makeData() {
        // 创建账户
        Account acc = new Account(Name = 'Test Account');
        insert acc;

        // 创建联系人，关联到账户
        Contact con1 = new Contact(FirstName = 'Test', LastName = 'Contact 1', AccountId = acc.Id);
        Contact con2 = new Contact(FirstName = 'Test', LastName = 'Contact 2', AccountId = acc.Id);
        insert new List<Contact>{con1, con2};

        // 创建自定义对象等其他共享数据
        // ...
    }

    @isTest
    static void testPositiveScenario() {
        // 在这里可以直接查询到 makeData() 中创建的数据，无需重新创建
        Account testAcc = [SELECT Id, Name FROM Account WHERE Name = 'Test Account' LIMIT 1];
        System.assertNotEquals(null, testAcc.Id);
        // ... 进行业务逻辑测试和断言
    }

    @isTest
    static void testNegativeScenario() {
        // 同样可以直接查询和使用 @testSetup 创建的数据
        // ...
    }
}

`@testSetup` 带来的好处

减少代码重复：所有测试方法共享一套数据创建逻辑，代码更精简。
提高效率：数据只创建一次，显著缩短了测试运行时间。
数据隔离与一致性：每个测试方法在运行时，都会获得一份 @testSetup 创建的全新数据副本。这意味着一个测试方法对数据的修改，不会影响到同类中的其他测试方法，保证了测试的独立性和一致性。

我当时非常推崇这种做法，因为它真正做到了测试数据的“一次准备，多处复用，相互隔离”。这也是我判断写测试类应该遵循的重要原则之一。

异步代码的考验：`Test.startTest()` 与 `Test.stopTest()`

在处理异步操作，比如 Queueable、Future 或 Batch Apex 时，测试又带来了新的挑战。我记得有一次，我写了一个 Queueable 类来处理一些耗时的后台逻辑，但在测试中无论如何都无法覆盖到它的 execute 方法。

最初的困惑

我的 Queueable 调用看起来没问题，但在测试运行时，代码覆盖率报告告诉我 execute 方法根本没被执行。我当时非常疑惑：难道异步代码就不能测试吗？或者测试方式有什么特别之处？

我的理解是：在标准的同步测试流中，这些异步操作只是被‘排队’了，并不会立即执行。它们被放入了 Salesforce 的异步队列中，等待系统资源可用时才会被处理。因此，如果我只是简单地调用 System.enqueueJob() 然后立即检查结果，那结果自然是‘未执行’的。

`Test.startTest()` 和 `Test.stopTest()` 的作用

后来，我了解到 Test.startTest() 和 Test.stopTest() 这两个静态方法是专门用来处理这种情况的。它们不仅仅是为了让异步代码能被测试到，更是为了在一个隔离且受控的环境下验证其行为。

强制同步执行异步操作：当 Test.stopTest() 被调用时，所有在 Test.startTest() 之后被提交的异步操作（Queueable、Future、Batch Apex 和 Scheduled Apex）都会被强制同步执行。这意味着我可以在 Test.stopTest() 之后立即检查这些异步操作的结果。
Governor Limit 重置：更重要的是，Test.startTest() 会在它被调用时重置当前事务的 Governor Limits。这意味着在 Test.startTest() 之后执行的代码，会有一个全新的、完整的 Governor Limit 额度可以使用，这对于测试那些接近极限的逻辑非常有帮助。它有效地隔离了测试设置代码（setup code）的资源消耗和实际被测代码的资源消耗。


@isTest
private class MyQueueableServiceTest {

    @isTest
    static void testQueueableExecution() {
        Test.startTest();

        // 调用触发 Queueable 的业务逻辑
        MyQueueableService.enqueueSomeJob(); 

        Test.stopTest();

        // 在这里，MyQueueableService 的 execute 方法已经被同步执行完毕
        // 我们可以查询数据库，验证 Queueable 带来的数据变化
        // System.assertEquals(...)
    }
}

这两个方法是测试异步代码的关键，它们让我能够模拟真实的异步执行环境，同时又能保持测试的同步性和可控性。这也是我判断测试异步代码的必用模式。

超越覆盖率：断言的价值

仅仅达到 75% 的代码覆盖率远远不够。代码被执行过，不代表它执行‘正确’了。我的经验告诉我，如果一个测试没有断言（assertions），那它就不是一个真正有效的测试。

为什么断言如此重要？

断言是测试的核心，它定义了我们对代码行为的预期。一个好的测试应该在执行代码后，通过 System.assertEquals()、System.assertNotEquals()、System.assert() 等方法来验证：

预期结果是否正确：比如，一个计算方法是否返回了正确的值。
数据是否按预期被修改：比如，一个触发器是否正确地更新了相关记录的字段。
异常是否被正确抛出：比如，当输入无效时，代码是否按预期抛出了自定义异常。
是否存在副作用：比如，某个操作是否意外地修改了不应该修改的数据。

我发现，写测试时，思考“我期望这个方法返回什么？”、“我期望这个操作导致数据库发生什么变化？”这些问题，会反过来帮助我更好地设计和理解业务逻辑。测试不仅仅是代码的副产品，它也是代码设计过程中的一个重要组成部分。

我倾向于为每个测试用例设置明确的断言，覆盖正常流程 (positive cases)、异常情况 (negative cases) 和边界条件 (edge cases)。例如，测试一个批量更新方法时，我会确保它能正确处理单条记录、多条记录以及空列表的情况，并断言每种情况下数据的状态变化。

当前看法与未解之谜

现在回过头看，Apex 测试类远不止是满足平台要求那么简单。它们是代码质量的基石，是防范回归的关键，也是重构时的信心来源。每当我需要修改一段老旧的 Apex 代码时，如果存在完善的测试覆盖，我就会更有信心去改动，因为我知道测试会帮我捕捉到潜在的副作用。

当然，测试也并非没有挑战。如何更好地模拟外部系统调用（Callouts）依然是一个值得深入探索的领域。虽然有 Test.setMock()，但在某些复杂场景下，模拟外部服务响应的复杂性本身就很高，如何编写既灵活又真实的 Mock 对象，始终是一个需要不断实践和优化的课题。

总的来说，Apex 测试类是我 Salesforce 开发旅程中不可或缺的一部分，它们让我从一个只关注“代码跑起来”的开发者，成长为一个关注“代码稳定性和可靠性”的实践者。

Salesforce中文网