How to extract as much performance improvement as possible from unit tests

I urge everyone to start adopting the following unit testing methodology because it will save a huge amount of time in your deployments and ensure quality coding simultaneously.

Some people like Paul Battisson have done a lot of work on using Mock objects to avoid doing DMLs to create test data for your unit tests, but isn't exclusively to help in this area,but this is what I want to concentrate on.
However Pauls work at the moment doesn't help the situation where you want to test your Triggers. Testing Triggers properly should involve bulk testing of 200 record DMLs. The only problem in doing this is every time you deploy every unit test of every Trigger will run 200 record DMLs, this is of course very expensive and will slow down your deployments.
So what we need is a combinationof using Mock objects to test the bulk of your code, but to test your Triggers on first deploy we should test a full 200 record DMLs, and on subsequent deploys to just test a handful of records, say 10 records, which is less expensive and so will speed up your deployments. But with the built in ability to increase the number of DMLs whenever you need to.

It is likely that your trigger tests cumulatively account for 90% + of the DMLs that go on in all your test classes. So adddress this issue and you address the issue around deployment times being so long.

First of all look at Pauls work on Mock objects
https://github.com/pbattisson/Advanced-Force.com-Testing 


Testing Triggers by Luke Emberton and Steven Fouracre 

When deploying a trigger for the first time set a custom setting to 200,
so that up to 200 records are created in your unit test, after
deployment lower this to 10, so that future deployments are not slowed
down but the unit tests are still tested. If you are currently in an
empty sandbox, then the unit test needs to be written to populate the custom setting
with a default value of say10 to test 10 DMLs.

First step is to setup our Triggers correctly. Have a look at this article about the Trigger Pattern
 http://www.embracingthecloud.com/2010/07/08/ASimpleTriggerTemplateForSalesforce.aspx

By testing the trigger I will indirectly test the class, so
you could just test the trigger, but that is not unit testing, because
what happens if the class is called from other classes and the trigger and unit test to the trigger is
removed, there is now potentially nothing covering the class. Also I like to make it obvious where the
unit test is that tests the trigger and class.

So testing the trigger, you need to test bulk DMLs, for the class just test for 1 record. To setup the test data I use the same function to test both trigger and class, or for you classes you could use Pauls Mock objects.

The following example is to test update and deletion triggers, but can be slightly modified for inserts as well, by ensuring whatever value is entered in the CS the number of new records is created.

public static void setupData(integer createData){

cLines = <<do soql>>; //find out how many records exist in this org

if (createData > cLines.size()){//there isnt enough records in this org, so you need to create more records
 
 for (integer i=1; i<=(createData - cLines.size()); i++){
          ……..blah blah……create any extra records required
  }
 
}
else{
//there are enough records in this org you don't need to create any more
}


}


createData tells the function how many records to setup. The code in the If statement only
creates however number of extra records are required to be created to test the trigger or class.

Of course this means you need to use @istest(SeeAllData=True)

The actual testmethod will likely be very similar for both tests for the trigger and class, except the number you are passing to setupData()


When testing the class the integer createData is set to 1, when testing the Trigger it is taken from a custom setting ( CS ) in the org. So when you are deploying your project, the CS is set to 200 to fully test your trigger, then it is lowered to say 10, so the Trigger is still tested for bulk operations, but future deployments are not slowed down by trying to create 200 DMLs. Of course the CS can be changed whenever you like for future upgrades to your trigger.

Create a CS called Test_Triggers__c , with field Records__c.
In your trigger test

                    Test_Triggers__c testTrigs = Test_Triggers__c.getinstance(<<object name>>);
                    integer recordCreate = (Integer)((testTrigs != null) ? testTrigs.Records__c : 10);
Now pass recordCreate to setupData()

If your CS is empty it will just set it to 10, otherwise it will pass the number of records to create to setupData(), and this function will soql the number of existing records in the org and work out how many more is needed to create. So after deployment lower your CS from 200 to 10 to continue testing your triggers for bulk operations.

Efficient, easily manageable and quality testing by Luke Emberton and Steven Fouracre
Enjoy!