Automated testing of chained Queueable jobs in Salesforce












5















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.
Salesforce documentation for chaining queueables in apex tests



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.










share|improve this question























  • if response of 1st condition triggers queuebale of second, why not make callouuts first and then do DML?

    – user3209853
    Feb 20 at 18:46
















5















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.
Salesforce documentation for chaining queueables in apex tests



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.










share|improve this question























  • if response of 1st condition triggers queuebale of second, why not make callouuts first and then do DML?

    – user3209853
    Feb 20 at 18:46














5












5








5








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.
Salesforce documentation for chaining queueables in apex tests



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.










share|improve this question














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.
Salesforce documentation for chaining queueables in apex tests



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.







queueable-interface queueable-apex asynchronous-testing queueable






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Feb 20 at 18:25









Json Bourne ShellJson Bourne Shell

137111




137111













  • if response of 1st condition triggers queuebale of second, why not make callouuts first and then do DML?

    – user3209853
    Feb 20 at 18:46



















  • if response of 1st condition triggers queuebale of second, why not make callouuts first and then do DML?

    – user3209853
    Feb 20 at 18:46

















if response of 1st condition triggers queuebale of second, why not make callouuts first and then do DML?

– user3209853
Feb 20 at 18:46





if response of 1st condition triggers queuebale of second, why not make callouuts first and then do DML?

– user3209853
Feb 20 at 18:46










2 Answers
2






active

oldest

votes


















6














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.






share|improve this answer































    5














    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)






    share|improve this answer


























    • Thank you for the response. I have queueable because I want to make callouts in the after triggers. By calling the execute() synchronously, I wont be able to make callouts to outside systems in the trigger.

      – Json Bourne Shell
      Feb 20 at 18:42











    • @JsonBourneShell you can make at least one (maybe more, I'm not 100% sure right now) call to a queueable class in a unit test if you make use of Test.startTest() and Test.stopTest() as part of your test method. The point still stands, though, that testing the functionality of your queueable classes in your test for your trigger handler is closer to integration testing than unit testing.

      – Derek F
      Feb 20 at 18:47











    • Yes, you've hit the nail on the head here. I am looking for a way to write automated smoke / integration test so that I will be able to catch it beforehand.

      – Json Bourne Shell
      Feb 20 at 18:51











    • N.B. GITHUB apexmocks being a more leveraged approach IMHO than building the stub API framework for one use case

      – cropredy
      Feb 20 at 20:33













    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "459"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f251054%2fautomated-testing-of-chained-queueable-jobs-in-salesforce%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    6














    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.






    share|improve this answer




























      6














      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.






      share|improve this answer


























        6












        6








        6







        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.






        share|improve this 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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Feb 20 at 18:46









        sfdcfoxsfdcfox

        261k12207452




        261k12207452

























            5














            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)






            share|improve this answer


























            • Thank you for the response. I have queueable because I want to make callouts in the after triggers. By calling the execute() synchronously, I wont be able to make callouts to outside systems in the trigger.

              – Json Bourne Shell
              Feb 20 at 18:42











            • @JsonBourneShell you can make at least one (maybe more, I'm not 100% sure right now) call to a queueable class in a unit test if you make use of Test.startTest() and Test.stopTest() as part of your test method. The point still stands, though, that testing the functionality of your queueable classes in your test for your trigger handler is closer to integration testing than unit testing.

              – Derek F
              Feb 20 at 18:47











            • Yes, you've hit the nail on the head here. I am looking for a way to write automated smoke / integration test so that I will be able to catch it beforehand.

              – Json Bourne Shell
              Feb 20 at 18:51











            • N.B. GITHUB apexmocks being a more leveraged approach IMHO than building the stub API framework for one use case

              – cropredy
              Feb 20 at 20:33


















            5














            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)






            share|improve this answer


























            • Thank you for the response. I have queueable because I want to make callouts in the after triggers. By calling the execute() synchronously, I wont be able to make callouts to outside systems in the trigger.

              – Json Bourne Shell
              Feb 20 at 18:42











            • @JsonBourneShell you can make at least one (maybe more, I'm not 100% sure right now) call to a queueable class in a unit test if you make use of Test.startTest() and Test.stopTest() as part of your test method. The point still stands, though, that testing the functionality of your queueable classes in your test for your trigger handler is closer to integration testing than unit testing.

              – Derek F
              Feb 20 at 18:47











            • Yes, you've hit the nail on the head here. I am looking for a way to write automated smoke / integration test so that I will be able to catch it beforehand.

              – Json Bourne Shell
              Feb 20 at 18:51











            • N.B. GITHUB apexmocks being a more leveraged approach IMHO than building the stub API framework for one use case

              – cropredy
              Feb 20 at 20:33
















            5












            5








            5







            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)






            share|improve this answer















            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)







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Feb 20 at 18:51

























            answered Feb 20 at 18:36









            Derek FDerek F

            20.7k52253




            20.7k52253













            • Thank you for the response. I have queueable because I want to make callouts in the after triggers. By calling the execute() synchronously, I wont be able to make callouts to outside systems in the trigger.

              – Json Bourne Shell
              Feb 20 at 18:42











            • @JsonBourneShell you can make at least one (maybe more, I'm not 100% sure right now) call to a queueable class in a unit test if you make use of Test.startTest() and Test.stopTest() as part of your test method. The point still stands, though, that testing the functionality of your queueable classes in your test for your trigger handler is closer to integration testing than unit testing.

              – Derek F
              Feb 20 at 18:47











            • Yes, you've hit the nail on the head here. I am looking for a way to write automated smoke / integration test so that I will be able to catch it beforehand.

              – Json Bourne Shell
              Feb 20 at 18:51











            • N.B. GITHUB apexmocks being a more leveraged approach IMHO than building the stub API framework for one use case

              – cropredy
              Feb 20 at 20:33





















            • Thank you for the response. I have queueable because I want to make callouts in the after triggers. By calling the execute() synchronously, I wont be able to make callouts to outside systems in the trigger.

              – Json Bourne Shell
              Feb 20 at 18:42











            • @JsonBourneShell you can make at least one (maybe more, I'm not 100% sure right now) call to a queueable class in a unit test if you make use of Test.startTest() and Test.stopTest() as part of your test method. The point still stands, though, that testing the functionality of your queueable classes in your test for your trigger handler is closer to integration testing than unit testing.

              – Derek F
              Feb 20 at 18:47











            • Yes, you've hit the nail on the head here. I am looking for a way to write automated smoke / integration test so that I will be able to catch it beforehand.

              – Json Bourne Shell
              Feb 20 at 18:51











            • N.B. GITHUB apexmocks being a more leveraged approach IMHO than building the stub API framework for one use case

              – cropredy
              Feb 20 at 20:33



















            Thank you for the response. I have queueable because I want to make callouts in the after triggers. By calling the execute() synchronously, I wont be able to make callouts to outside systems in the trigger.

            – Json Bourne Shell
            Feb 20 at 18:42





            Thank you for the response. I have queueable because I want to make callouts in the after triggers. By calling the execute() synchronously, I wont be able to make callouts to outside systems in the trigger.

            – Json Bourne Shell
            Feb 20 at 18:42













            @JsonBourneShell you can make at least one (maybe more, I'm not 100% sure right now) call to a queueable class in a unit test if you make use of Test.startTest() and Test.stopTest() as part of your test method. The point still stands, though, that testing the functionality of your queueable classes in your test for your trigger handler is closer to integration testing than unit testing.

            – Derek F
            Feb 20 at 18:47





            @JsonBourneShell you can make at least one (maybe more, I'm not 100% sure right now) call to a queueable class in a unit test if you make use of Test.startTest() and Test.stopTest() as part of your test method. The point still stands, though, that testing the functionality of your queueable classes in your test for your trigger handler is closer to integration testing than unit testing.

            – Derek F
            Feb 20 at 18:47













            Yes, you've hit the nail on the head here. I am looking for a way to write automated smoke / integration test so that I will be able to catch it beforehand.

            – Json Bourne Shell
            Feb 20 at 18:51





            Yes, you've hit the nail on the head here. I am looking for a way to write automated smoke / integration test so that I will be able to catch it beforehand.

            – Json Bourne Shell
            Feb 20 at 18:51













            N.B. GITHUB apexmocks being a more leveraged approach IMHO than building the stub API framework for one use case

            – cropredy
            Feb 20 at 20:33







            N.B. GITHUB apexmocks being a more leveraged approach IMHO than building the stub API framework for one use case

            – cropredy
            Feb 20 at 20:33




















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Salesforce Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f251054%2fautomated-testing-of-chained-queueable-jobs-in-salesforce%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Probability when a professor distributes a quiz and homework assignment to a class of n students.

            Aardman Animations

            Are they similar matrix