测试Salesforce链式Queueable Apex时遇最大栈深度错误求助

在Salesforce测试框架中，Test.startTest()和Test.stopTest()会将所有已入队的异步任务同步串行执行在同一个上下文栈中。当你的TestQueue1在execute方法中调用System.enqueueJob(TestQueue2)时，TestQueue2的execute会立刻在同一个执行栈内被触发执行——哪怕只有两层链式，加上测试框架本身的栈占用，也可能刚好触达Salesforce的栈深度上限，从而抛出Maximum stack depth has been reached错误。

以下几种方案可以解决这个问题：

• 拆分异步任务的测试执行
  不要依赖单次Test.stopTest()触发所有链式任务。先入队TestQueue1并调用Test.stopTest()执行它，确认其执行逻辑正常后，再手动入队TestQueue2并再次调用Test.stopTest()。这种方式适合单独验证每个Queueable的功能，但无法完全模拟生产环境中自动链式触发的场景。

• 测试环境下模拟链式调用而非实际入队
  在TestQueue1的execute方法中，通过Test.isRunningTest()判断是否处于测试环境，调整执行逻辑：

  public void execute(QueueableContext context) {
      System.debug('in testQueue1: ');
      if(!accounts.isEmpty()) {
          if(Test.isRunningTest()) {
              // 测试环境直接调用TestQueue2的execute方法，跳过入队
              new TestQueue2().execute(context);
          } else {
              // 生产环境正常执行入队逻辑
              Id jobId = System.enqueueJob(new TestQueue2());
          }
      }
  }
  

  这样既可以验证链式逻辑的正确性，又避免了测试框架中同步入队导致的栈深度问题。

• 通过任务状态查询验证链式触发
  如果需要严格模拟生产环境的链式触发流程，可以不在测试中立即执行异步任务，而是在Test.stopTest()后查询AsyncApexJob记录，验证TestQueue1和TestQueue2的任务是否都被成功入队并标记为完成状态。这种方式不需要同步执行所有任务，自然不会触发栈深度限制。

你已经排除了自调用、DML和触发器的影响，所以核心问题完全来自测试框架对异步任务的同步执行机制。上述方案中，第二种模拟链式调用的方式最贴近生产逻辑，同时能解决栈深度问题，是优先推荐的方案。

内容的提问来源于stack exchange，提问作者Luke Sharon