[SalesForce] Automated testing of chained Queueable jobs in Salesforce

I am currently writing a queueable class for asynchronous processing in my triggers since triggers do not allow callouts. I am going achieve it by calling a class which implements the queueable interface.
When reading the documentation I found out that you can have 50 queueable in one transaction but can call only one queueable from a queueable class.

https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_queueing_jobs.htm

Also, I can not chain the queueable jobs in apex test.

Example of working class / method:
Below class will work in its own transaction.

EventTriggerHandler.afterInsert(){
  Boolean bDoACallout = isCalloutNecessary();
  if(bDoACallout){
    System.enqueueJob(new EventTriggerHandlerCallout((Map<Id, Event>)Trigger.newMap));
   }
  Boolean bSecondCondition = isSecondConditionTrue();
  if(bSecondCondition){
    System.enqueueJob(new Trial1Queueable((Map<Id, Event>)Trigger.newMap));
   }
  Boolean bThirdCondition = isThirdConditionTrue();
  if(bThirdCondition){
    System.enqueueJob(new Trial2Queueable((Map<Id, Event>)Trigger.newMap));
  } 
}

Now, Salesforce documentation says, above mentioned code will work but wont be testable and I need to wrap it around Test.isRunningTest() and I may be wrong but what I understood from that is, these queueables needs to be tested separately and not in the test of EventTriggerHandler itself.

EventTriggerHandler.afterInsert(){
  Boolean bDoACallout = isCalloutNecessary();
  if(bDoACallout){
    System.enqueueJob(new EventTriggerHandlerCallout((Map<Id, Event>)Trigger.newMap));
   }
  Boolean bSecondCondition = isSecondConditionTrue();
  if(bSecondCondition){
    System.enqueueJob(new Trial1Queueable((Map<Id, Event>)Trigger.newMap));
   }
  Boolean bThirdCondition = isThirdConditionTrue();
  if(bThirdCondition){
    System.enqueueJob(new Trial2Queueable((Map<Id, Event>)Trigger.newMap));
  } 
}

This was working on its own as expected all the unit tests were working too per my understanding of queueable class and apex tests. Above code will not work when Event is being created from a queueable itself. We did a clean up exercise to consolidate all the logic in one queueable class.
But, I am not sure how to code a smoke test / automated tests so that we catch these beforehand without manual tests of entire org.

Best Answer

When you need more than one execution, but you want to test the asynchronous code independently, you can cheat by rolling them back. Here's an example in a unit test:

Test.startTest();
SavePoint sp = Database.setSavePoint();

// Replace this with real code
executeTheTrigger();

// Do any asserts, etc...

// Roll back the transaction
Database.rollback(sp);
Test.stopTest();

Then, you can get a natural 100% coverage of your trigger code without this error. Note that you should prefer to do any assertions before you roll back the state, since any modifications will disappear. Also remember you'll need to unit test your Queueables independently.

Related Solutions

[SalesForce] Are queueable jobs actually queueable

No, I don't believe the order of execution for Queueable Apex is defined. They "will be processed when system resources become available" (Source). The AsyncApexJob records that represent the queued jobs don't have a concept of ordering (other than the created date).

Instead you should use chaining, which is defend in the docs as:

If you need to run a job after some other processing is done first by another job, you can chain queueable jobs.

The Apex Flex Queue for batch jobs is something different again. It does however have the concept of reordering.

[SalesForce] Chaining Queueables: Clarification & Practical Usage

There's two modes of operation in Salesforce: synchronous and asynchronous. The rule is that if you're synchronous, you get 50 jobs for that transaction. Once you go asynchronous, you get only one child allowed. This is done to prevent "rabbits." A rabbit is code that reproduces until it consumes all available resources. In a Queueable, this would be a rabbit:

public class Rabbit implements Queueable {
    public void execute(QueueableContext context) {
        System.enqueueJob(this);
        System.enqueueJob(this);
    }
}

As you can see, one job would spawn 2, those would spawn 4, and those would spawn 8... you end up with exponential growth. Without governor limits, doing such a thing could bring the servers down, which is why we have limits in place, so that this can't happen.

While this is an explicit example, it would be more challenging to necessarily find this condition when you have multiple triggers that each may enqueue a job, perhaps indefinitely.

So, generally speaking, you'll need to make a design choice in order to fix the problem. On potential solution would be to write a utility class, perhaps something like the following:

public class QueueableUtil implements Queueable {
    Queueable[] payload;
    static QueueableUtil self;
    QueueableUtil(Queueable item) {
        payload = new Queueable[] { item };
    }
    public static Id enqueueJob(Queueable item) {
        if(!System.isQueueable()) {
            return System.enqueueJob(new QueueableUtil(item));
        } else {
            self.payload.add(item);
            return null;
        }
    }
    public void execute(QueueableContext context) {
        self = this;
        payload.remove(0).execute(context);
        if(!payload.isEmpty()) {
            System.enqueueJob(this);
        }
    }
}

Now, you can call your items using the new method:

QueueableUtil.enqueueJob(new ContactTriggerHandlerQueueable(Trigger.new));

If you're in a Queueable context, your job will be added to a queue to be executed, and if you're not, you'll be queued normally.

I haven't tested this, but it looks like it should work. Please keep in mind that you may hit heap limits if your queue gets too big, so try to design your Queueable jobs to have as small of a footprint as possible.

Keep in mind that this requires discipline; you'll need to use this utility all the time in order for it to be useful, because it will only queue itself from a non-queueable context so as to not violate the chaining rules.

You may also need to consider adding additional logic if you need to worry about scheduled, future, and batchable contexts, which have similar restrictions (only one call per transaction). I wouldn't consider this a full solution, but it's better than nothing.

Keep in mind that if you use a method like this, it is entirely possible to chain even more than 50 jobs in a single transaction. You may want to add some safeguards to prevent runaway processes.

Best Answer

Related Solutions

[SalesForce] Are queueable jobs actually queueable

[SalesForce] Chaining Queueables: Clarification & Practical Usage

Related Topic