Testing bulk clone operation

Question

After doing enough Google search and scratching my brain, I have decided to post here and seek for suggestions.

Here is the background:

• An opportunity has multiple order & order line item records
• In rare scenarios the number of Orders & OLI can go upto 20k-40k
• As part of renewal process, new opportunity is cloned from the existing opportunity. Now all the related orders & OLIs should be created (cloned) as well

Here is what we are doing:

• Calling a batch class from the trigger handler class to clone/create new orders & OLIs
• All good here so far.

Now, coming to the question. We are trying to test if this is working fine, if we are within the limits when the records are more than 10k (the DML limit). I am struggling to get answers to test this through test class. Is it possible to create more than 10k records in test classes? If yes, how?

The other option was to test this in Full Copy. But I would like to know if there is a way to do this in test classes.

Looking for suggestions and experiences.

Answer 1

You cannot test this in a unit test that actually performs DML. The DML rows limit is 10,000 in a single transaction, and even using Test.startTest() and Test.stopTest() to execute your batch class synchronously does not allow you to run more than one batch invocation in a unit test.

For that reason, your batch class will only in fact handle as many records as the batch size you supply, and that could never rise above 10,000 even if other limits were not hit along the way.

However, if you can contrive to test your logic with purely in-memory sObjects, without performing any DML, you may be able to test logical paths that are intended to run on large data volume and validate that their behavior is correct. (You might still hit some other limit in your unit test, like CPU time, but it's at least plausible that this could work). From your description, it sounds like this might not be necessary, though - if the logic is the same regardless of data volume, you should reserve LDV testing for a phase of your QA process outside of the unit test.

In order to try the above, you may need to apply dependency injection to parts of your code, particularly anything that runs a query, in order to inject this synthetic, in-memory data into the class under test, but it depends heavily on how you've structured it.

As far as performance and LDV testing goes, performing these tests in a Full Copy sandbox is going to be the best solution; you just cannot simulate this circumstance fully in a unit test. Doing that testing in a real environment will also allow you to vet query performance and selectivity in a data skew situation such as you describe, something you can't touch in a unit test at all.