Author Archive

One of the most often asked questions is “how do I test a trigger I have written”. This normally stems from the misunderstanding of how triggers run and what they actually do. A trigger is a piece of code that is defined to run either “before” or “after” a particular action is performed upon a record, namely “insert”, “update”, “undelete” or “delete”.

In the definition of your trigger you will know what context the trigger is occurring in (for example “after insert”) and you will have an understanding of the functionality this trigger will be performing. To test a trigger you must create an apex class which acts upon the record in the desired way (e.g. inserting a record) so that the trigger code will then get executed.

The example trigger shown below is a before trigger on a test object we have called TestObject__c with two text fields (Field1__c and Field2__c) and a Name field. When a record of this object type is sent to be inserted, before the insert occurs, our trigger runs and checks to see whether or not Field2__c is null (i.e. has been set) and if it has been set it then sets Field1__c to have this same value (trivial yes, but hopefully illustrative).

So we know what this trigger is doing, but what do we have to do to test it? At the highest level we want to insert a record and check that the trigger behaves as expected. So if we set a value for Field2__c then Field1__c will also get that value. What if we don’t set a value? Then we expect Field1__c to be null, so we need to test for that as well. Finally, when testing triggers we should attempt to do some volume testing as triggers are where we can easiest hit governor limits through looping etc (I know the limits are now increased, but good practice is a still good practice). So we will also include a test to insert 100 records and check they act as expected.

You will see in the code below that I have three private static methods in my test class to manage the insertion of the records. I recommend doing it this way for a number of reasons:

You will have cleaner and better structured code

You will reduce the number of places where bugs can be

Your tests will be more consistent and easier to update and maintain

You can easily add extra tests

You can create very exact specifications for your tests easily and also remove a lot of data dependency problems

What do I mean by removing data dependency problems? If you are writing a trigger on a standard SObject (e.g. Account) or for a product that will be upgraded, then your tests will run against orgs where data of that type exists. Having very clear and structured data setup methods allows you to minimise the chance of someone already having records like those you are going to be considering (you will notice I use PBTest to help keep mine unique as it is an unlikely name to be given to an object and so I am unlikely to mistakenly retrieve the wrong object).
@isTest
private class TestObjectTriggerTest
{

The code is self-explanatory and should give enough insight as to how a trigger is tested properly. It runs and passes at 100%.

A final note is that trigger testing is extremely important, not only because Salesforce mandate it but because trigger code is some of the most used code you have in your system. As a system grows and its rules become more complex with multiple records being created automatically of the back of the creation of other records, your trigger code will be used extensively and therefore thorough testing (including volumes) is a must.