DEX455

课程介绍

Shipping Invoice测试应用完整示例：Calculate触发器(Map收集唯一InvoiceID/批量SOQL/subtract标志三种操作模式/updateMap.values批量DML)、ShippingDiscount触发器(before insert条件折扣)、测试类(@testSetup共享数据/每种操作正向+负向/insert+update+delete+discount五种验证/Test.startTest+stopTest)、应用架构总结(触发器逻辑分离Handler/Map+Set批量数据处理/事务原子性/Governor Limit意识)。

课程章节

本课程共有 5 个章节

• 1

  Testing the Shipping Invoice Application

  第 469 页

  来，咱们聊聊这个重点内容。你知道在Salesforce里开发应用，尤其要把应用打包发布，一个硬性要求就是单元测试必须覆盖至少75%的代码。这个不是可选的，是必须的。为什么呢？因为Salesforce要保证你的代码在生产环境不会出大问题，测试覆盖率就是一道质量门槛。 今天我们看的这个航运发票应用程序，就是一个很好的完整示例。它里面有一个触发器，这个触发器能自动计算运费金额，还会应用折扣。比如一笔订单，加了商品之后，触发器会自动帮你算好该收多少运费，并看看要不要打折，非常智能。 然后为了验证这个触发器是不是可靠，我们写了一个专门的测试类。这个测试类可不简单，它覆盖了好几种场景：正常插入商品、更新商品数量、删除商品、运费折扣是不是正确地应用了，甚至还包括一些负面的测试场景——比如我故意操作不当，看系统会不会把不该做的事做了。这样能保证代码在各种边界条件下都是安全的。 还有一点很关键，这个代码特别遵循了“批量触发器”的最佳实践。什么意思呢？就是在处理数据的时候，我们用集合和映射来批量处理，而不是一条一条的循环处理。比如用List来存要更新的记录，用Map来快速查找数据，这样处理大批量数据时又快又稳，不会碰到Salesforce的调控限制。 好，下一张幻灯片我们就会深入这个例子，看具体是怎么写的。但你先记住，75%的测试覆盖率是一个底线，这个航运发票的例子就是展示如何通过好的设计和充分的测试，轻松达到甚至超过这个要求。

  ▶ 播放视频 查看详情
• 2

  Calculate Trigger — Bulk Processing Pattern

  第 470 页

  同学们，大家好，今天我们来讲一个非常经典的Apex触发器模式，你可以把它叫做“计算触发器”，幻灯片上展示的就是这个批量处理的基本样板。 这个触发器最巧妙的地方在于，它充分利用了触发器上下文里的 `Trigger.new` 和 `Trigger.old`。对插入和更新操作，它直接去 `Trigger.new` 里拿全新的记录；而对于删除操作，它就去 `Trigger.old` 里拿那些即将被删掉的数据。同时呢，它还引入了一个“减法标志”，通俗点说就是一个方向指示，用来判断到底是要加总金额，还是要减总金额，这样就能灵活应对增、删、改不同的事件了。 紧接着，它就进入最关键的批量思维环节。它没有一条条地去处理记录，而是先把所有相关的运输发票ID，不管是新的还是旧的，全部收集到一个集合里。然后，它用一句 SOQL，配合 `IN` 条件，一次性把所有要调整的发票记录查出来。这有什么好处呢？它彻底绕开了一个大坑，就是在循环里面执行 SOQL 查询。如果一条记录就查一次，数据一多，立刻就会撞上 Salesforce 的调控器限制，程序就崩了。而这里，一次查询搞定所有，非常安全。 把发票记录查出来之后，这个触发器还特别严谨。它先用断言声明来验证一下数据，确保我们拿到的记录和期望的状态一致，这就像给自己上了一道保险。接着，它就在内存里批量计算，把发票的总额重新算一遍。它算得很细，包括了细项金额、重量、折扣、税费，最后汇总出一个明确的总计。 整个模式从始至终都遵守所有的调控器限制，不管一次进来多少条记录，它都能高效、稳定地处理。这就是我们常说的“批量触发器模式”，你在实际开发中一定要学会并多用它。 好，关于这个Slide的内容，我们就先聊到这儿。下节课见！

  ▶ 播放视频 查看详情
• 3

  ShippingDiscount Trigger & Test Class

  第 471 页

  同学们，今天我们来看一个关于运输折扣触发器的例子。这个触发器的作用是，当订单里的运输折扣发生变化时，自动调整订单的总金额。 为了确保这个触发器不出错，我们写了一个测试类，专门验证五个关键操作。 第一步，我们插入一些订单项。触发计算后，检查订单总数是不是正确算出来了。 第二步，我们更新订单项，比如改个数量，然后验证总数有没有重新计算。 第三步，删除一个订单项，看看总数有没有相应地减少。 第四步，专门测试运输折扣。我们给订单加一笔折扣，然后断言最终总金额Grand Total已经包含了折扣。 最后一步，我们故意输入一些坏数据，比如负数折扣或者空值，再使用断言来确认系统拒绝了这些无效输入，不会让它混进去。 整个测试的套路都一样：先准备好测试数据，然后执行你要测的那个操作，接着去数据库里查出更新后的记录，最后用断言检查结果是不是你期望的样子。 这样，我们就能放心地让运输折扣触发器上线工作了。

  ▶ 播放视频 查看详情
• 4

  Application Architecture & Best Practices Summary

  第 472 页

  咱们今天聊的这个“Shipping Invoice”应用程序啊，是个很好的例子，演示了Apex代码怎么写才算是生产级别的。你看，它用了两个自定义对象，一个是，Shipping_Invoice__c，，就是装运发票；另一个是，Item__c，，代表发票里的明细项。数据模型就这么简单。 业务逻辑怎么放呢？它用了两个触发器，一个叫，Calculate，，专门负责当明细项Item有任何改变时，自动重新计算发票上的总额；另一个叫，ShippingDiscount，，负责应用运费折扣。你看，这俩触发器各管各的，这叫，单一责任原则，，改了计算逻辑不会影响折扣逻辑，维护起来就方便。 光这样还不够，这个应用还遵循了好几个关键的设计模式。首先，，批量处理，——触发器里不用单个记录循环，而是用，集合，和，一个SOQL查询，就把所有相关记录抓出来，避免 limit 问题，效率高。其次，，数据验证用断言，，比如某个金额不该是负数，直接就在代码里 assert，不合规就抛异常，保证数据干净。 测试这边写得也特别全，覆盖了所有的DML操作、所有业务逻辑路径，还特意测了，负面场景，，比如传个空值、传个异常高的金额，确保程序不会崩。这样一来，总共就实现了，100%的代码覆盖率，。 你看，这些模式加在一起，就做出了一个既稳健又好维护的Apex实现。咱们以后写触发器，完全可以照着这个路子来。好了，这个Slide的核心点就是这些。

  ▶ 播放视频 查看详情
• 5

  Slide 473

  第 473 页

  同学们，大家好！感谢大家一路坚持学完了Apex开发人员指南，我们终于迎来了最后一章。这一章，我们会用一个叫“航运发票”的完整小应用，把前面学过的所有Apex核心原则串起来，让大家看到它们是怎么在一个真实能跑的生产级应用里协同工作的。 这个航运发票应用里，我们会重点看几个关键部分。首先是Calculate触发器，它处理发票计算的时候，特意采用了批量模式。也就是说，它用Set集合先把要处理的数据收拢起来，然后只发一条SOQL查询，一次性把相关数据取出来处理，而不是在循环里反复问数据库。这个写法就是为了遵守Salesforce的州长限制，保证大批量数据进来的时候也不会超限崩溃，这就是咱们常说的“州长限制意识”。 然后是ShippingDiscount触发器，它负责业务规则的自动化。比如根据订单金额、运送方式自动算出折扣，让折扣逻辑清清楚楚地封装在触发器里，而不是散落在各处。 测试也是一个重头戏。为了确保这个应用万无一失，我们写了一个很全面的测试类，它覆盖了所有五个核心操作场景：插入新发票、更新发票、删除发票、应用折扣的计算，还有故意传入负数这样的边界情况。这种测试思路，本质上就是测试驱动开发，先想好各种可能的情况再写代码，让代码更加健壮。 整个应用的架构也遵循了清晰的设计模式，把业务逻辑、数据操作、触发器职责划分得明明白白，后期维护和扩展都会很轻松。 总而言之，这次演练就是想让大家看到，每个Apex开发者都应该在自己的应用里，去实践批量模式、去小心州长限制、去写全面的系统测试。只有这样，我们写出的代码才能稳稳地跑在Salesforce平台上，这最后一章就是一个给力的总结和示范。 好了，航运发票应用的讲解就到这里，恭喜大家完成整个指南的学习！希望大家能把学到的这些好习惯，用在你未来的项目里。谢谢！

  ▶ 播放视频 查看详情