无论是处于Salesforce Flow之旅的哪个阶段，都应该知道，在将其部署到生产环境之前需要测试所有自动化或功能，并且在部署后，确保没有异常。
在新工具和版本之后，对如何测试Record-triggered Flows进行了许多改进。本篇文章将介绍这些工具和使用它们的最佳实践，以及一些帮助减少在Flow测试期间发生错误的有效方法。
调试工具
Flow Debug工具已经存在了很长一段时间。借助此工具，Flow开发人员可以从多个角度模拟正在运行的Flow，同时查看每个元素是如何被命中的。
虽然调试工具多年来一直允许Flow开发人员测试新的或者修改过的声明式自动化，但这仍然是一个相当繁琐的过程。Flow开发人员需要在每次运行之前配置调试运行，并且不能保存具有特定变量值的特定运行。
Apex允许以测试类的形式运行单独的Apex方法和持久化测试。长期以来，Salesforce一直被问及他们何时会发布类似的Record-triggered Flows工具，随着Summer '22的发布，Salesforce以Flow Tests的形式为该问题提供了答案。
将Debug运行转换为Flow Test
只需单击几下，即可创建一个调试来运行Salesforce Flow测试。这意味着，即使运行一次性测试，然后决定要在多个场合运行它，也不必从头开始。
成功执行调试运行后，可以看到页面右上角有一个新的“Convert to Test”操作。点击“Convert to Test”，新的测试界面会弹出一个窗口，让你将调试运行转换为Flow Test。
值得注意的是，如果调试运行因某种原因失败了，“Convert to Test”按钮将显示为灰色，无法从中创建新测试。你需要确保Flow能够成功完成调试运行，然后再创建Flow Test。
Record-Triggered Flow测试工具
Summer '22中的一个新工具，允许Flow开发人员轻松地对Record-Triggered Flow执行一系列批量测试。Flow开发人员可以针对Record-Triggered Flow创建多个测试以逐个执行或一起执行，以查看它是否按预期执行。
Flow开发人员可以使用Flow Test来创建符合业务需求的自动化测试场景，确保已创建的Record-Triggered Flow正在执行业务预期的操作。它们还可用于确保在对Flow进行更改时不会破坏现有功能。
创建用户故事
作为Flow开发人员，应该详细了解企业使用Salesforce创建自动化功能的原因，并且将这些要求转化为用户故事。
用户故事遵循特定的格式：“作为一个{角色}，我想完成 {任务}， 以实现 {目标}”。例如，“作为一名销售团队成员，我希望能够记录新的潜在客户信息，以便跟踪交易”。
这些用户故事是构建Flow的原因，因此确保你构建的Flow满足需求是有意义的。创建符合用户故事的Flow Test是实现这一点的最佳方式。当发生更改时，你可以轻松地一次性测试和重新测试它们，并查看通过列表，以及失败列表。
Apex测试最佳实践适用于Flow Test
Apex测试的功能与Flow Test非常相似。针对Apex方法编写一个测试类，然后将该方法作为测试运行。Apex测试类编写中的许多最佳实践也可以应用于Flow Test。
Flow开发人员应该尝试用测试覆盖尽可能多的Flow。这不仅可以确保正在构建的内容与最初推动创新的需求直接相关，而且还可以最大限度地减少最终用户将看到的错误数量。
如果Flow使用Decisions，请务必创建适用于每个分支的测试。这再次确保了Flow中的所有路径都经过了彻底测试。
值得注意的是，Flow Test的功能类似于调试工具和Apex测试。应用于记录的任何更改实际上都不会提交，因此不需要在之后进行清理。
使用故障路径设计Flow以通过测试
确保在设计Flow时，计划在某些点（例如数据元素，创建、更新、获取或删除）发生错误，并使用故障路径等功能为这些错误做好准备。
新的Flow测试工具现阶段仅适用于Record-Triggered Flow。Salesforce未来可能会扩展到Schedule-Triggered Flow、Autolaunched Flow和Platform Event-Triggered Flow。但是在此之前，仍然需要继续使用替代方法，来确保这些Flow类型正常运行（例如使用Debug Flow、执行基于场景的手动测试等）。
到此，希望各位对Salesforce开发有了初步的了解，我们会继续分享SF领域的干货知识，想学习并加入这个领域的小伙伴可以关注【自由侠部落】。
