Apex Scheduler — Testing, Tracking, Limits & Best Practices

同学们，今天我们来聊聊怎么测试 Salesforce 里头的定时作业，也就是 Scheduled Apex。 咱们先看重点：，测试定时作业，。在测试类里，如果你直接调用 `System.schedule()`，它是异步的，不会马上跑。那怎么让它马上执行呢？答案很简单——用 `Test.startTest()` 和 `Test.stopTest()` 包起来。这样，计时器就会被“骗”过去，系统会同步执行你安排的那个作业，方便我们验证结果。 那怎么跟踪这个作业跑没跑、什么时候再跑呢？你可以查一个叫 ，CronTrigger， 的对象。通过 SOQL 查询它，你能拿到两个关键字段：`TimesTriggered`（已经触发了多少次）和 `NextFireTime`（下次什么时候触发）。如果想再详细点，知道作业的名字和类型，还可以关联查询 ，CronJobDetail，，里面存着作业的名称和 `JobType`。 说到 `JobType`，有个小技巧：当你计算所有计划 Apex 作业时，记得过滤 `JobType = '7'`，这个数字 '7' 就是代表计划 Apex 作业。 接下来咱们得知道系统的，限制，：一个 Salesforce 环境里，最多只能有 100 个计划作业。而且，所有非正式员工（比如合作伙伴用户）加起来，每天总共只能执行 25 万次计划作业。这里要注意，我说的“临时工”实际上是指各种 license 类型的用户，他们共享这个限额。 最后，讲几条，最佳实践，： - 从触发器里直接安排计划作业要极其谨慎，很容易碰到限制。最好把具体的业务逻辑委托给一个单独的类去处理。 - 如果你的计划作业需要跟外部系统交互，记得用能支持 callout 的接口（比如 `Database.AllowsCallouts`）。 - 系统维护或者停机之后，有些计划作业可能会暂停，你要记得写脚本或者手动去重新安排它们。 - 沙箱刷新之后，所有计划作业都会被清掉，因为沙箱是从生产环境克隆的快照，所以你得重新部署或安排。 - 还有一点，作业的状态在整个运行过程中会一直保留，除非你用了“临时性”的作业（transient），那种作业跑完就自动清理了。所以正常作业的状态是一直存在的。 好了，这些就是关于定时作业测试和管理的核心要点，有什么问题随时提出来。