DEX450

课程介绍

让我们来聊聊Salesforce中的测试。在这个模块里，我们要讨论的是你作为开发者，在编写代码时，测试这部分代码的责任是什么，以及什么是“完整”的测试。 首先，测试你的代码是你的责任。这意味着你需要确保你的代码不仅能够正常工作，而且还要在各种情况下都能稳定运行。这包括处理错误输入、边界条件以及确保代码的性能符合预期。 那么，什么是“完整”的测试呢？完整测试意味着你需要覆盖所有可能的场景和用例。这包括正常流程、异常流程以及边界条件。你需要确保你的测试案例能够验证代码的每一个部分，包括所有的分支和逻辑路径。 接下来，我们来谈谈总体测试策略。一个好的测试策略应该包括单元测试、集成测试和系统测试。单元测试关注的是代码的最小部分，确保每个函数或方法都能正确执行。集成测试则是确保不同的模块或服务能够正确地协同工作。系统测试则是在整个系统层面上进行，确保所有部分都能一起正常工作。 在Salesforce中，我们通常使用开发人员沙盒来进行测试。开发人员沙盒是一个隔离的环境，你可以在不影响生产环境的情况下测试你的代码。这让你可以自由地尝试和修改代码，而不用担心会影响到实际的业务操作。 最后，完整的沙盒是一个更接近生产环境的测试环境。它不仅包含你的代码，还包括数据、配置和用户信息。这使得你可以在一个非常接近真实世界的环境中进行测试，确保你的代码在实际部署时能够顺利运行。 总之，测试是确保你的代码质量和稳定性的关键步骤。通过全面的测试策略和适当的测试环境，你可以大大提高你的代码的可靠性和性能。

课程章节

本课程共有 16 个章节

• 1

  Module 12: Testing Strategies

  第 313 页

  让我们来聊聊Salesforce中的测试。在这个模块里，我们要讨论的是你作为开发者，在编写代码时，测试这部分代码的责任是什么，以及什么是“完整”的测试。 首先，测试你的代码是你的责任。这意味着你需要确保你的代码不仅能够正常工作，而且还要在各种情况下都能稳定运行。这包括处理错误输入、边界条件以及确保代码的性能符合预期。 那么，什么是“完整”的测试呢？完整测试意味着你需要覆盖所有可能的场景和用例。这包括正常流程、异常流程以及边界条件。你需要确保你的测试案例能够验证代码的每一个部分，包括所有的分支和逻辑路径。 接下来，我们来谈谈总体测试策略。一个好的测试策略应该包括单元测试、集成测试和系统测试。单元测试关注的是代码的最小部分，确保每个函数或方法都能正确执行。集成测试则是确保不同的模块或服务能够正确地协同工作。系统测试则是在整个系统层面上进行，确保所有部分都能一起正常工作。 在Salesforce中，我们通常使用开发人员沙盒来进行测试。开发人员沙盒是一个隔离的环境，你可以在不影响生产环境的情况下测试你的代码。这让你可以自由地尝试和修改代码，而不用担心会影响到实际的业务操作。 最后，完整的沙盒是一个更接近生产环境的测试环境。它不仅包含你的代码，还包括数据、配置和用户信息。这使得你可以在一个非常接近真实世界的环境中进行测试，确保你的代码在实际部署时能够顺利运行。 总之，测试是确保你的代码质量和稳定性的关键步骤。通过全面的测试策略和适当的测试环境，你可以大大提高你的代码的可靠性和性能。

  ▶ 播放视频 查看详情
• 2

  Module Objectives - 314

  第 314 页

  同学们，今天我们来聊聊Salesforce开发中的一个重要环节——确保你的Apex代码在部署到生产环境之前是经过充分测试的。这个环节非常关键，因为它能帮助我们避免在生产环境中遇到各种意外问题。 首先，我们要明确一个目标：在将代码从沙箱环境迁移到生产环境之前，确保你的代码覆盖率达到了100%。虽然Salesforce官方要求的最低覆盖率是75%，但为了更高的代码质量和稳定性，我们建议追求100%的覆盖率。这意味着你的测试用例需要覆盖到代码中的每一个可能的执行路径。 接下来，我们来看看如何实现这个目标。首先，你需要确定你的代码覆盖率。这可以通过Salesforce提供的工具来完成，它会告诉你哪些代码行已经被测试覆盖，哪些还没有。这样，你就可以有针对性地编写测试用例，确保每一行代码都被测试到。 然后，使用最佳实践来创建测试。这意味着你的测试用例不仅要覆盖代码，还要确保它们能够有效地验证代码的功能和逻辑。编写测试时，要考虑到各种边界情况和异常情况，确保代码在这些情况下也能正常工作。 最后，确保你的Apex代码符合你的编码标准。这不仅包括代码的格式和风格，还包括代码的可读性和可维护性。良好的编码标准可以帮助团队更高效地协作，减少错误的发生。 总之，通过确保100%的代码覆盖率和遵循最佳实践来创建测试，你可以大大提高代码的质量和稳定性，确保在将代码部署到生产环境时不会遇到意外问题。希望这些内容对你们有所帮助，祝你们在Salesforce开发中取得成功！

  ▶ 播放视频 查看详情
• 3

  Module Agenda - 315

  第 315 页

  同学们，今天我们来聊聊Salesforce中的测试模块。首先，我们要了解的是，测试在Salesforce中是非常重要的，因为它帮助我们确保我们的代码在部署到生产环境之前是稳定和可靠的。 首先，我们会讨论测试的副作用。在编写测试时，我们可能会不小心引入一些副作用，比如改变了数据库中的数据，这可能会影响到其他测试或者实际的生产数据。因此，我们需要非常小心，确保我们的测试是独立的，不会影响到其他部分。 接下来，我们会学习如何使用最佳实践进行测试。这包括编写清晰、可维护的测试代码，确保测试覆盖了所有重要的业务逻辑，以及使用模拟数据来避免对实际数据的依赖。 在模块12的课程中，我们会详细介绍Apex测试框架。Apex测试框架是Salesforce提供的一个强大的工具，它允许我们编写和执行测试用例，以确保我们的Apex代码按预期工作。我们会学习如何创建测试类，如何编写测试方法，以及如何运行和评估测试结果。 记住，良好的测试习惯不仅能帮助我们捕捉错误，还能提高代码的质量和可维护性。所以，让我们开始学习如何有效地进行测试吧！

  ▶ 播放视频 查看详情
• 4

  Avoiding Issues Caused By Tests Running in Parallel

  第 316 页

  让我们来聊聊如何在Salesforce中避免在并行测试执行时遇到的一些常见问题。首先，我们需要理解什么是并行测试执行。简单来说，就是Salesforce可以同时运行多个测试，这样可以节省时间。但是，这有时候也会带来一些问题，比如数据冲突。 第一个常见的问题是“Unable_to_lock_row”错误。这个错误通常发生在两个测试同时尝试更新同一条记录时。想象一下，如果两个人同时想要编辑同一个文档，系统就会混乱，不知道应该保存谁的更改。在Salesforce中，这种情况会导致锁定错误。 为了避免这种问题，我们有几个策略： 1. ，创建自己的测试数据，：不要依赖现有的组织数据，而是为每个测试类创建自己的测试数据。这可以通过使用`@testSetup`注解来实现。这样，每个测试都有自己的数据，不会与其他测试冲突。 2. ，禁用并行测试，：如果你发现并行测试导致问题，可以选择关闭它。这可以通过Salesforce的设置来完成。具体步骤是：进入设置，找到“开发”部分，然后选择“Apex测试执行”，在选项中选择“禁用并行Apex测试”。 3. ，重构代码，：如果可能，尝试将相关的测试方法放在同一个测试类中。虽然测试类是并行运行的，但类中的测试方法是按顺序执行的，这可以减少冲突的可能性。 最后，记得在时间允许的情况下进行演示，这样你可以更直观地看到这些策略的效果。希望这些信息对你有帮助，让你在Salesforce的测试过程中更加顺利！

  ▶ 播放视频 查看详情
• 5

  How is Code Coverage Calculated?

  第 317 页

  让我们来聊聊Salesforce中的代码覆盖率是怎么一回事。首先，想象一下你的代码就像一本书，而代码覆盖率就是告诉你这本书有多少页被真正“读过”了。在Salesforce中，这个“读过”的部分指的是那些被测试执行过的代码行。 现在，不是所有的代码行都会被计入覆盖率。比如，注释、空行、只有部分语句的行、System.DEBUG()语句，还有那些只有大括号{}的行，这些都不会被算作覆盖行。但是，如果一行上有多个语句，它们会被当作一行来计算。如果是一个多行的表达式，那么每一行都会单独计算。 举个例子，假设你有一段代码，我们可以把它分成几个部分：C1、C2、T1、C3、T2和C4。如果测试覆盖了C1、C2、T1和C3，那么覆盖率就是75%，因为T2和C4没有被覆盖。但是，每个触发器至少需要有一行被覆盖，这是最低要求。不过，C4这一部分不需要被覆盖。 Salesforce要求你的代码覆盖率至少达到75%，但为了代码的质量和稳定性，你应该努力达到90%以上。 计算代码覆盖率的时候，有两个关键的时间点：一个是你显式执行测试的时候，另一个是你进行部署的时候。这两个时间点都会计算覆盖率，但它们是不同的。显式执行测试通常是通过用户界面来调用的，比如使用开发者控制台。测试会排队异步运行，完成后，代码覆盖率表会根据测试结果更新。 希望这个解释能帮助你理解Salesforce中的代码覆盖率是如何计算的。记住，高覆盖率意味着你的代码更健壮，更不容易出错。所以，尽量让你的覆盖率保持在90%以上吧！

  ▶ 播放视频 查看详情
• 6

  Viewing Testing Results and Code Coverage

  第 318 页

  让我们来聊聊如何在Salesforce中查看测试结果和代码覆盖率。这其实是一个非常重要的步骤，尤其是在你准备将代码部署到生产环境之前。 首先，当你运行了Apex测试后，你会想要检查测试是否通过了，以及你的代码覆盖率是多少。你可以在开发人员控制台里找到这些信息。想象一下，你打开了一个测试结果的页面，这里会显示哪些测试通过了，哪些失败了。失败的部分通常会以红色高亮显示，这样你一眼就能看出哪里出了问题。 接下来，我们来看看代码覆盖率。代码覆盖率是一个百分比，它告诉你你的测试覆盖了多少代码。Salesforce要求至少75%的代码覆盖率才能部署到生产环境。这个覆盖率是通过计算所有被测试覆盖的代码行数除以总代码行数得出的。在开发人员控制台的“测试”选项卡里，你可以看到一个“总体代码覆盖率”面板，这里会显示每个Apex类的覆盖率以及整体的覆盖率。 这里有个小技巧，当你查看覆盖率时，绿色的部分表示这些代码已经被测试覆盖了，而红色的部分则表示这些代码还没有被测试到。你可以点击这些红色的部分，看看是哪些代码没有被覆盖，然后回去修改你的测试用例，确保这些代码也能被测试到。 最后，记住在进行部署时，Salesforce会自动运行测试并计算覆盖率。如果覆盖率不达标，部署就会失败。而且，这些覆盖率数据不会存储在数据库中，这是为了支持部署失败时的回滚操作。如果部署失败，所有的更改都会被撤销，包括那些覆盖率数据，这样可以避免指向不存在的代码行。 希望这些信息对你有帮助，让你在Salesforce的世界里更加得心应手！

  ▶ 播放视频 查看详情
• 7

  Stored Code Coverage Calculations

  第 319 页

  让我们来聊聊Salesforce中的代码覆盖率这个话题。首先，代码覆盖率是一个非常重要的指标，它告诉我们有多少比例的代码被测试覆盖了。这个比例越高，说明我们的代码质量越好，潜在的错误也越少。 但是，这里有一个小陷阱。你可能会看到某个代码覆盖率的百分比，但这个数字可能是旧的。为什么呢？因为Salesforce不会自动更新这个百分比，除非你重新运行测试。所以，如果你最近对代码做了修改，比如添加了新的触发器或者修改了现有的类，那么旧的覆盖率数字就不再准确了。 举个例子，假设你的组织中有50行代码，这些代码都被测试覆盖了，所以覆盖率是100%。然后，你添加了一个新的触发器，这个触发器有50行代码，但这些代码还没有被测试覆盖。现在，你的总代码行数变成了100行，但只有50行被测试覆盖了。所以，你的代码覆盖率就从100%下降到了50%。 因此，为了得到准确的代码覆盖率，你需要定期重新运行测试。这样，Salesforce会重新计算覆盖率，确保你看到的数字是最新的。记住，只有当测试重新运行后，代码覆盖率的百分比才会更新。 所以，下次当你看到代码覆盖率的时候，记得问自己：“这个数字是最新的吗？”如果不是，那就赶紧重新运行测试吧！这样，你就能确保你的代码质量始终保持在最佳状态。

  ▶ 播放视频 查看详情
• 8

  12-1: Explore Code Coverage

  第 320 页

  同学们，今天我们来聊聊Salesforce中的代码覆盖率。这是一个非常重要的概念，尤其是在我们编写Apex代码时。代码覆盖率可以帮助我们了解我们的测试类是否足够全面，是否覆盖了所有可能的代码路径。 首先，我们需要准备一个实验室环境。这个环境可以是你的开发者组织，或者是一个沙盒环境。确保你有权限在这个环境中运行Apex代码和测试类。 接下来，我们要运行一个测试类。你可以选择一个你已经写好的测试类，或者创建一个新的。运行测试类的方法很简单，打开开发者控制台，找到你的测试类，然后点击“运行测试”。 运行完测试类后，我们就可以查看代码覆盖范围了。在开发者控制台中，点击“测试”标签，然后选择“查看覆盖范围”。这里你会看到一个百分比，这个百分比表示你的测试类覆盖了多少代码。理想情况下，我们希望这个百分比尽可能高，最好是100%。 最后，我们的目标是使用开发者控制台来探索代码覆盖范围。你可以尝试修改你的测试类，看看覆盖范围如何变化。你也可以尝试添加新的测试方法，看看是否能提高覆盖率。 好了，这就是今天的任务。希望你们能通过这个实验，更好地理解代码覆盖率的重要性。现在，轮到你动手试试吧！

  ▶ 播放视频 查看详情
• 9

  Module Agenda - 321

  第 321 页

  同学们，今天我们来聊聊Salesforce中的测试模块。首先，我们要了解的是测试的副作用。在编程中，当我们运行测试时，有时候会无意中改变数据或者系统的状态，这就是所谓的副作用。在Salesforce中，我们特别要注意这一点，因为我们的测试可能会影响到实际的数据。 接下来，我们会讨论如何使用最佳实践来进行测试。最佳实践就是那些被广泛认可和推荐的方法，它们可以帮助我们更有效地进行测试，减少错误，提高代码的质量。在Salesforce中，这包括编写独立的测试用例，确保测试覆盖所有可能的场景，以及使用断言来验证测试结果。 现在，让我们进入模块12：测试课程。在这一部分，我会先给大家介绍Apex测试框架。Apex是Salesforce的一种编程语言，而Apex测试框架则是用来测试Apex代码的工具。这个框架可以帮助我们确保我们的代码在部署到生产环境之前是可靠的，没有bug的。 记住，测试是开发过程中非常重要的一环，它帮助我们确保我们的应用是稳定和可靠的。所以，让我们开始学习如何有效地进行测试吧！

  ▶ 播放视频 查看详情
• 10

  Testing Data Conditions: Valid, Invalid, and Bulk

  第 322 页

  同学们，今天我们来聊聊Salesforce中的测试数据条件，特别是关于有效、无效和批量数据的处理。我会用简单的语言来解释这些概念，确保大家都能跟上。 首先，我们来看，有效数据，。有效数据指的是那些符合我们预期，能够被系统正确处理的数据。在我们的例子中，有效数据包括两种情况：一种是带有电话号码的账户，另一种是没有电话号码的账户。虽然空电话看起来可能不太完整，但如果我们的系统设计是允许这种情况的，那么它也是有效的。所以，我们需要测试这两种情况：插入一个带有电话号码的账户，以及插入一个没有电话号码的账户。 接下来是，无效数据，。无效数据通常是指那些不符合我们预期，或者系统没有明确处理的数据。在这个例子中，如果我们有一个空的名单，这就是一种无效数据。因为我们的系统可能没有设计去处理这种情况，所以我们需要确保我们的代码能够优雅地处理这种异常情况，而不是崩溃。 最后，我们来看，批量数据，。批量数据测试是为了确保我们的代码能够处理大量的数据，而不仅仅是单个记录。在我们的例子中，我们需要测试插入200个账户，其中一些有电话号码，另一些没有。这可以帮助我们确保代码在处理数据列表时能够正常工作，而不仅仅是单个记录。 总结一下，我们需要进行以下测试： 1. 插入一个带有电话号码的单一账户。 2. 插入一个没有电话号码的单一账户。 3. 插入一个包含200个账户的列表，其中一些有电话号码，另一些没有。 通过这些测试，我们可以确保我们的代码在各种情况下都能稳定运行。希望这些解释对大家有帮助，如果有任何问题，随时提问！

  ▶ 播放视频 查看详情
• 11

  Testing Limits

  第 323 页

  让我们来聊聊Salesforce中的测试方法，特别是`startTest`和`stopTest`这两个方法。想象一下，你在做一道菜，`startTest`就像是开始烹饪的那一刻，而`stopTest`则是你完成烹饪，准备上菜的时候。 首先，`startTest`方法在测试代码中标记了一个点，表示测试正式开始。在这之前，你可以做一些准备工作，比如设置变量、填充数据等，这些都是为了确保测试能够顺利进行。每个测试方法中，`startTest`只能被调用一次。 当你调用`startTest`之后，系统会给你一组新的调控器限制。这就像是你在烹饪时，突然有了更多的食材可以使用。但是，一旦你调用`stopTest`，系统就会回到原来的限制，就像是你用完了额外的食材，只能回到原来的食材库。 `stopTest`方法则是在测试结束时标记的点。它和`startTest`是成对使用的，每个测试方法中也只能调用一次。在`stopTest`之后执行的代码，会回到调用`startTest`之前的限制。 此外，`startTest`之后的所有异步调用都会被系统收集起来，当执行`stopTest`时，这些异步进程会同步运行。这就像是你在烹饪时，同时开了几个锅，但最终所有锅里的菜都会在同一时间完成。 所以，使用`startTest`和`stopTest`方法，可以帮助你更好地控制测试的流程和限制，确保测试的准确性和效率。希望这个解释能帮助你更好地理解这两个方法的作用！

  ▶ 播放视频 查看详情
• 12

  Testing with Sharing Using System.RunAs(User u)

  第 324 页

  今天我们来聊聊Salesforce中的System.RunAs方法，这是一个在测试中非常有用的工具。想象一下，你正在编写一些Apex代码，这些代码需要根据不同的用户权限和记录共享规则来运行。但是，Apex代码默认是在系统模式下运行的，这意味着它不会考虑当前用户的权限或记录共享设置。这时候，System.RunAs就派上用场了。 使用System.RunAs，你可以在测试方法中模拟一个特定用户的上下文。这样，你就可以测试你的代码在不同用户权限下的行为，特别是记录共享的部分。不过要注意，RunAs方法只会影响记录共享，不会改变用户的权限或字段级别的权限。 举个例子，假设你有一个用户u，你想测试这个用户是否能访问某些记录。你可以在测试方法中使用System.RunAs(u)来模拟这个用户的上下文，然后检查相关的记录共享规则是否按预期工作。 另外，RunAs方法还有一个很酷的特性，就是它不受用户许可证的限制。即使你的组织没有额外的用户许可证，你仍然可以使用RunAs来创建新用户进行测试。 还有一点需要注意的是，每次调用RunAs都会计入DML语句的总数。所以如果你在测试中频繁使用RunAs，可能会影响到DML语句的限制。 最后，RunAs方法还有一个重载版本，可以接受包版本作为参数。这个版本允许你测试特定版本的托管包代码。 总结一下，System.RunAs是一个非常强大的工具，可以帮助你在测试中模拟不同用户的上下文，特别是用于测试记录共享规则。希望这些信息对你有帮助！如果你有更多问题，随时问我哦。

  ▶ 播放视频 查看详情
• 13

  Setting Up Data for System.RunAs(User u)

  第 325 页

  同学们，今天我们来聊聊如何在Salesforce中使用`System.runAs`方法来模拟不同用户的操作，并通过测试来验证我们的代码。我们有两个代码片段需要解释，分别是代码A和代码B。我会一步步引导大家理解这些代码的作用。 ### 代码A的解释 首先，我们来看代码A。这段代码的主要目的是计算今天创建的证书持有记录的总数。具体步骤如下： 1. ，计算记录总数，：我们使用SOQL查询来查找今天创建的证书持有记录。这里需要注意的是，我们没有使用`AllData=TRUE`，所以只会计算当前用户可见的记录。根据我们的测试设置，应该只有两条记录。 2. ，查找TA1用户，：接下来，我们使用SOQL查询来找到名为TA1的用户。TA1是一个培训管理员用户。 3. ，设置用户上下文，：使用`System.runAs(TA1)`，我们将当前的用户上下文切换到TA1用户。这意味着接下来的操作都会以TA1的身份执行。 4. ，调用方法并统计记录，：我们调用`CountDailyCertHeld`方法，这个方法会返回当前用户（即TA1）今天创建的证书持有记录的总数。 5. ，断言验证，：最后，我们使用`System.assertEquals`来验证`CountDailyCertHeld`方法返回的记录数是否与我们之前计算的记录数一致。如果一致，测试通过；如果不一致，测试失败。 ### 代码B的解释 接下来，我们来看代码B。这段代码的目的是验证一个没有证书记录的用户（UA2）在调用`CountDailyCertHeld`方法时，返回的记录数是否为0。具体步骤如下： 1. ，查找UA2用户，：我们使用SOQL查询来找到名为UA2的用户。UA2是一个标准用户，并且没有任何证书记录。 2. ，设置用户上下文，：使用`System.runAs(UA2)`，我们将当前的用户上下文切换到UA2用户。这意味着接下来的操作都会以UA2的身份执行。 3. ，调用方法并统计记录，：我们调用`CountDailyCertHeld`方法，这个方法会返回当前用户（即UA2）今天创建的证书持有记录的总数。由于UA2没有任何证书记录，所以返回的记录数应该是0。 4. ，断言验证，：最后，我们使用`System.assertEquals`来验证`CountDailyCertHeld`方法返回的记录数是否为0。如果是0，测试通过；如果不是0，测试失败。 ### 测试设置方法 在开始测试之前，我们需要设置一些测试数据。这就是`@TestSetup`方法的作用。在这个方法中，我们创建了三个用户： 1. ，培训管理员（TA1），：这是一个拥有管理权限的用户。 2. ，标准用户（UA2），：这是一个拥有两个证书记录的用户。 3. ，标准用户（UA3），：这是一个没有任何证书记录的用户。 通过这种方式，我们可以在测试中使用这些用户来验证我们的代码是否按预期工作。 ### 总结 通过这两段代码，我们学会了如何使用`System.runAs`来模拟不同用户的操作，并通过测试来验证我们的代码。我们首先计算了记录总数，然后切换用户上下文，最后通过断言来验证结果。希望这些内容对大家理解Salesforce中的测试方法有所帮助。如果有任何问题，欢迎随时提问！

  ▶ 播放视频 查看详情
• 14

  Breaking Up Your Test Classes

  第 326 页

  让我们来聊聊Salesforce中的测试课程要点。首先，想象一下你有一个商务舱，这是你的主要工作环境，所有的开发工作都在这里进行。然后，你还有一个测试舱，这是你用来测试代码的地方。这样做的好处是，你可以确保你的代码在投入生产环境之前是经过充分测试的。 现在，关于测试方法，我们提倡使用很多小测试方法，而不是一个大型的测试类。这样做有几个好处： 1. ，测试数据隔离，：每个小测试方法都有自己的测试数据，这样就不会因为数据冲突而导致测试失败。 2. ，测试类可以并行运行，：小测试方法可以同时运行，这样可以加快测试的速度。 3. ，测试案例隔离，：每个测试方法都是独立的，一个测试方法的失败不会影响到其他测试方法。 教学点的最佳做法是，每个班（即每个开发环境）都应该有一个对应的测试班。这意味着，不要创建单个的大型测试类，而是应该创建多个小型的、专注的测试类。这样做可以确保每个测试类都专注于测试一个特定的功能或模块，从而提高测试的准确性和效率。 总之，通过分解测试课程要点，使用小测试方法，并确保每个班都有一个测试班，你可以更有效地进行Salesforce开发，确保代码的质量和稳定性。希望这些信息对你有所帮助！

  ▶ 播放视频 查看详情
• 15

  Ensuring Test Data is Created Properly When Deployed

  第 327 页

  同学们，今天我们来聊聊在Salesforce部署时，如何确保正确创建测试数据。这里有两个关键点需要注意： 首先，，确保加载静态资源，。静态资源，比如我们这里提到的“Test Holidays”，在生产环境中必须是可用的。这意味着在部署之前，你需要确认这些资源已经上传并且可以在生产环境中访问。如果静态资源没有正确加载，那么依赖于这些资源的测试数据就无法正确创建，这会导致测试失败。 其次，，不要硬编码ID，。在Salesforce中，每个记录都有一个唯一的ID，这个ID在不同的环境中是不一样的。如果你在测试数据中硬编码了某个ID，比如第6行提到的配置文件ID，那么这个ID在生产环境中可能就不存在了。这会导致第8行的代码无法正确执行，因为它在尝试插入一个不存在的ID。为了避免这种情况，你应该避免在测试数据中使用硬编码的ID，而是使用动态的方式来获取或创建这些ID。 总结一下，确保静态资源可用和避免硬编码ID是确保测试数据正确创建的两个重要步骤。这样做可以帮助你避免在部署时遇到不必要的麻烦。希望这些信息对你们有帮助！

  ▶ 播放视频 查看详情
• 16

  Key Takeaways - 328

  第 328 页

  让我们来聊聊Salesforce测试中的一些关键要点。首先，测试代码时，可能会遇到一些副作用，比如影响代码覆盖率的计算。这时候，你可以通过重新运行测试来刷新这些计算结果，确保数据的准确性。 在计算代码覆盖率时，不是所有的代码都会被计入。比如，空白行和调试语句就不会影响你的代码覆盖率百分比。所以，即使你看到覆盖率不是100%，也不必过于担心，只要确保核心逻辑被充分测试即可。 要实现条件语句的100%覆盖率，你需要测试每一个可能的分支。这意味着，如果你的代码中有多个条件判断，每个条件都需要被测试到，这样才能确保代码的健壮性。 在编写测试数据时，尽量避免硬编码ID。硬编码ID可能会导致测试在不同环境中失败。相反，应该动态生成数据，这样测试会更加灵活和可靠。 为了全面测试你的代码，不仅要测试正常情况，还要测试各种异常情况和批量数据。这样可以确保你的代码在各种情况下都能正常工作。 System.runAs() 是一个非常有用的方法，它可以帮助你测试共享模型。通过这个方法，你可以模拟不同用户的权限，确保你的共享规则和权限设置是正确的。 最后，Test类中有一些方法可以帮助你划定测试方法中的新上下文边界。这对于测试调节器限制特别有用，可以确保你的代码在资源限制下也能正常运行。 总结一下，测试是确保代码质量的关键步骤。通过全面、细致的测试，你可以大大提高代码的可靠性和稳定性。希望这些要点能帮助你在Salesforce开发中更加得心应手！

  ▶ 播放视频 查看详情