Salesforce recommends that we test the code in bulk, especially triggers. So we are expected to insert, update and delete records in bulk inside the test classes as per good coding standards. My query is how do we choose the number of records we need to test this on. Will subjecting 200 records to DML to test the bulkification be efficient. Do we face some drawbacks if we try to do so with more than 200 record? Thanks


(What follows may contain bits of heresy..... and applies mostly to non managed package use cases)

The reason to do bulk testing (> 100 records) is to ferret out bad bulkification practices in the code being tested - which might include code written by yourself or by others.

The reason to do bulk testing with more than 200 records is to ferret out trigger recursion control that, frankly, uses a single static Boolean, rather than a map(set) of IDs that have previously been processed

The reason to do bulk testing < 100 records is to make sure your code can handle lists and not get confused with improperly constructed maps or their usage.

If you and your colleagues know what you are doing, a far more fruitful use of your time is to write testmethods and asserts that test business logic and build up a solid regression suite. Equally, a more fruitful use of your time is to practice separation of concerns, refactoring, and anything that makes the code base more readable and maintainable. In my orgs, I long since stopped doing bulk testing of 100+ rows (unless there was something performance related I was worried about) as I don't (no longer :-) )make rookie mistakes with SOQL inside of for loops.

I do bulk testing by passing lists of sobjects into methods that are supposed to handle lists (or DML on triggers) so as to verify that lists of size 0 and greater than 1 are properly handled, even going so far as to provide a mixed set of use cases within one list so a single transaction can be simulated for a Data Loader use case.

That said, a good regression suite should also include bulk testing > 100/200 in case a future colleague is a "rookie". So gauge your time accordingly.

  • I was typing out something very similar, so either we're both on to something or we're both heretics. Bulk testing can be useful if the code being tested must be guaranteed to handle a certain minimum number of records (and thus a single trigger chunk must not consume more than a given number of queries and the like). In all but one case that I've personally come across so far, however, bulk testing using more than 10-20 records just increases the time the test takes to run with no discernible benefit. – Derek F Feb 29 '16 at 16:58
  • @DerekF. I completely agree. Not to mention filling debug logs with noise. – cropredy Feb 29 '16 at 17:00
  • @crop1645 Really useful insight into the scenario. – Prajith Feb 29 '16 at 17:29

Since the biggest risk is SOQL in a for loop, I usually do this at the top of my test class:

static final Integer RECORD_COUNT = Limits.getLimitQueries() + 1;

It totally depends on your use case that what will happen after 200 records. But yes for the bulk testing purpose you might consider 200 records. Use https://developer.salesforce.com/page/An_Introduction_to_Apex_Code_Test_Methods this for basic information on test class

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.