I have written a class which implements queueable interface and creates PDFs and saves them as attachments. Which is working fine.
public class ExpensePDF_Async_Helper implements Queueable, Database.AllowsCallouts{
private Set<Id> idset = new Set<Id>();
public ExpensePDF_Async_Helper(set<id> approvedIdset){
idset = approvedIdset;
}
public void execute(QueueableContext qc)
{
Integer allowedCallouts = Limits.getLimitCallouts() - Limits.getCallouts();
if(allowedCallouts <=0)
return;
list<expense_report__c> pdfsTocreate = new list<expense_report__c>();
for(Expense_report__c repo :[select PDF_created__c from expense_report__c where id in:Idset LIMIT :allowedCallouts])
{
if(repo.PDF_created__c == false)
{
// callout for getContentasPDF
ExpenseReportPDF.savePDFattachment(repo.id);
repo.PDF_Created__c = true;
pdfsTocreate.add(repo);
}
}
update PDFsTocreate;// this line doesn't execute in Unit test
}
}
Test Class 1: I see that one statements of my original class doesn't get executes in debug log
//Initialization here
Test.startTest();
System.enqueueJob(new ExpensePDF_Async_Helper(setId));
Test.stopTest();
list<attachment> attach = [select id from attachment where parentid in :setId];
System.assertEquals(2, attach.size());
System.assertEquals(true, expReport2.PDF_created__c);
I see that below one statements of my original class doesn't get execute if I use Test Class 1 & Test Class 2
update PDFsTocreate;
Test Class 2: One statement of my original class doesn't get executes
Test.startTest();
ExpensePDF_Async_Helper q = new ExpensePDF_Async_Helper(setId);
q.execute(null);
Test.stopTest();
list<attachment> attach = [select id from attachment where parentid in :setId];
System.assertEquals(2, attach.size());
System.assertEquals(true, expReport2.PDF_created__c);
The following statement doesn't get executed of my original class
update PDFsTocreate;
Can someone please explain why update statement in original class is not being called in both the test classes?
Limits.getLimitCallouts() - Limits.getCallouts()
are strictly non-negative. It doesn't make sense to check if they're less than 0.==
, but yes, that's the idea.