Htydjtk

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.

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.

A quick note to start off, the code you've provided right now doesn't display chaining of queueable classes. Chaining would be that you set up the execution of a queueable class from inside the execute() method of another queueable class. Rather, you have shown us a sequence of queueable calls.

A class that implements the Queueable interface, and the execute(QueueableContext ctx) method required to be in it, aren't really that different from any other class/method.

The QueueableContext parameter, which has official documentation, doesn't end up doing much of anything for you. It contains a job id, and nothing else (from what I can tell).

You can call the execute() method synchronously by simply passing in null as the argument for the execute() method (provided that you aren't actually using the job id).

So, in this case, testing your chained queueable methods breaks down to simply testing each method one at a time (likely in different test methods). You'll need to set up your test environment appropriately so that you are guaranteed to take the code path(s) that you want to test, but that's no different from your ordinary, run-of-the-mill unit test.

You may need to keep the chained calls behind a check against test.isRunningTest(), but that's about it.

You could possibly write a test that calls your queueable class from your trigger handler (not sure if you can call more than one per test), but that'd be less of a unit test, and more like an integration test.

+edit:

To write a test for your trigger handler that is closer to being a unit test, you should look into the Stub API to mock your calls to your queueable classes. The idea here is that you'll only care that the queueable class has its execute() method called (and not the result of running the actual code, which would be a unit test of the queueable classes themselves)