6

I have an Apex class that implements the Queueable interface which is used to remove custom objects attached to a set of Account Ids, and then inserts new custom objects to replace them.

The volume can be quite high (more than 10k removed, more than 10k inserted) without exceeding memory or CPU limits, so my implementation creates the List of new objects for a set of Account Ids, then passes the list of Account Ids and the new custom objects to the Queueable class through the constructor.

The execute() method first finds the custom objects for the give Account Ids and deletes 10k at a time (the DML row limit), calling itself recursively until all have been removed. It then performs the inserts in a similar way - 10k at a time - until all have been inserted.

The problem I am having is testing the Queueable calling itself recursively as only one job can be executed in the Test context at a time. Is the only way to cover (most) of the code to refactor it so that all except the System.enqueueJob() call is outside of the Queueable class?

5

This is one of those situations where you have to cheat to get perfect coverage. What you need to do is call your queueable's execute method without actually using the queueing mechanism-- then, the recursive call will fire appropriately, allowing you to get that perfect coverage.

Something like this:

// Do whatever initialization you need.
Test.startTest();
Queueable k = new MyQueueable();
// Do any other initialization here
// This will perform the necessary deletes
k.execute(null);
// This will cause the recursive call from execute to fire
Test.stopTest();

Alternatively, don't worry about getting perfect coverage. 95% is a perfectly acceptable goal.

  • That makes sense, I will need to decompose the delete/insert recursion and then it should be testable. Ordinarily I'm satisfied with 95%, but the org I am working in is at 74% coverage (yeah, I know...) so every little bit helps :) – doublesharp Dec 19 '15 at 22:21
  • 3
    And this is where understanding numbers comes into play. 74% means nothing. 74% of 100 is only 1 line missing. 74% of 10000 is 100 lines uncovered. So if your test between 95 and 100% is only a few lines it will make no difference in the overall coverage. Not directed at you just some thoughts as to why I hat the %'age coverage although I really do not have a better idea at the moment lol. Just take it into account when you are deciding if all this work is worth it or not. "What: is uncovered is more important that how many lines are uncovered. I know "Speaking to the choir" – Eric Dec 20 '15 at 0:10
  • 1
    @Eric - technically I agree, and in this case I was more curious about how to cover it than anything else. As far as my current situation, not sure on lines, but we have 2.9 million characters of Apex, and 74% coverage. One could say that a few lines here and there don't matter, but I would also argue that's what got my team into this situation in the first place :) – doublesharp Dec 20 '15 at 19:30
  • % coverage isn't my concern... its actually test case coverage that becomes impossible to achieve. Basically means any system that uses chained queueable context cannot have end to end testing. – NSjonas May 29 '17 at 17:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.