Parallel Test Execution & Testing Examples

同学们，咱们今天翻到这页幻灯片，来聊聊Apex测试时一个容易踩坑的问题，就是测试并行运行时的数据争用。 默认情况下，在Salesforce的用户界面里点击“运行全部测试”，系统为了节省时间，会把多个测试方法同时启动，这种并行执行本来挺好，但有个隐藏的麻烦。你想象一下，如果两个测试用例都在往同一个对象里插记录，而且碰巧用到相同的唯一索引值，比如两个测试都要创建邮箱一模一样的用户，由于它们同时跑，彼此不知道对方的存在，就有可能因为唯一性冲突导致其中一个莫名其妙地失败。又或者，它们争着更新同一条记录，还会发生记录锁的问题。这种概率性的失败特别让人头疼，因为单独跑某个测试明明都通过。 解决这个问题最简单的办法，就是在设置里关掉并行测试。你进到“设置”里，搜索“Apex Test”或者“Apex测试”，勾上那个“Disable Parallel Apex Testing”选项就行了。这样一来，测试就变成挨个排队执行，虽然慢了一点，但再也不会出现那种互相干扰的随机失败了。当然，更彻底的方案是你在设计测试数据时就注意隔离，让每个测试都使用自己独有的数据，但这节课我们先掌握这个快捷开关。 接下来咱们看这页强调的测试示例。作为开发者，我们光写正向案例远远不够，一定要把阳性、阴性、用户上下文隔离这些都覆盖到，这样的测试套件才真正牢靠。 先说阳性案例，就是代码正常工作的场景。你需要测试单条记录插入成功，也要测批量记录处理。比如你的代码里有个给客户批量发折扣的方法，那测试就要模拟传入200个客户，断言每个客户都正确更新了折扣字段。单独一条成功和批量都成功，才能确认没有边界漏洞。 然后是阴性案例，这更有讲究。阴性案例专门测试异常情况，比如记录违反了唯一约束，或者插入的时候超出了DML行数限制。幻灯片里特别提到了使用 `Assert.fail` 的写法，这可是个技巧。我来举个例子：假设你想测试一个方法，当传入的账户名重复时会抛异常。你就可以把调用写在 `try` 块里，然后紧挨着调用下一行写 `System.assert(false, '本应抛出异常却未抛出');` 注意老写法是 `Assert.fail`，现在都推荐用 `System.assert(false, '……')` ，效果一样。如果代码没抛异常，程序就走到这行，测试直接失败。如果它正确抛出了异常呢？就在 `catch` 块里，捕获出 `DmlException`，然后好好验证这个异常对象里带回来的详细信息。比如你可以验证 `e.getDmlFieldNames(0)` 里包不包含那个出错的字段名，再检查 `e.getDmlMessage(0)` 错误消息是否包含你预期的文字。这就是所谓的断言DML响应详细信息，能确保异常不仅是抛了，而且抛得准确，能指导用户修正数据。 最后，还要记住用 `System.runAs` 来模拟不同用户的测试。很多时候我们的数据是按角色或共享规则隔离的，你不亲自变成另一个用户跑