0

I have a trigger on an Account object that fires on update. In my unit test for the trigger, I create a test Account and insert it, which somehow causes the update trigger to fire. This causes an issue because I need to set up some more test objects to associate to the test account, and the premature firing of the update trigger causes a bug.

Here is what the trigger looks like:

trigger AccountTriggers on Account (before update, after update) {
    if(checkRecursion.runOnce()) {
        if(trigger.isUpdate && trigger.isBefore ) {
            AccountTriggerHelper.BeforeUpdateTriggers(trigger.new);
        }
    }
}

This is what my test setup looks like.

@testSetup private static void setup() {
        //Create the test objects
        Account acc = new Account();
        List<Contact> contactList = new List<Contact>();


        //Set up and insert Accounts
        acc.Name = 'Test Account';
        acc.Abby_Stage__c = '5.) Paid Account';
        acc.Type_of_Account__c = 'Abby Connect';
        acc.Lifecycle_Stage__c = 'Customer';
        acc.Update_Proration__c = true;
        acc.Update_Proration_End__c = false;
        insert acc; //UPDATE TRIGGER IS FIRED HERE

        //I set up a bunch more test data here that is required for the trigger
}

Is there anything I can do to stop the update trigger from firing on the insert? Or do I just need to set up my test to tell the difference between the trigger firing on insert vs. actually on update?

Thank you.

  • 1
    Do you have any workflow rules with field updates or process builder processes that update the record? Both of those could cause inserted records to also undergo an update. – Derek F May 13 at 23:04
  • 2
    That checkRecursion.runOnce() is also a bit concerning. The simple "static boolean" recursion guard is pretty flawed. Using a Static Set<Id> is better, but could still present issues in unit testing. If the "bug" you mentioned is related to this recursion guard, then you'll probably need to have a way to reset the recursion guard in unit tests. If it's a bug elsewhere, then that's an indication that you either need to do more thorough setup of test data or that there is truly an issue elsewhere in your code (perhaps you assumed a field would never be null, but it ends up null in the test). – Derek F May 13 at 23:11
  • Yeah it was a little bit too verbose to put in the initial post, but I am also creating opportunities in the test setup that I associate with the account. The trigger is supposed to parse through these opportunities and change a field, and then set a flag on the account. However, since the opportunities don't exist during test setup, it sets the flag on the account prematurely, then when the actual test update happens, the flag is set and the logic is skipped. – Douglas May 13 at 23:15
3

You most probably have a workflow or a process flow on Account object, that performs some update following the insert, and cause its update triggers to execute. However, this is completely normal and the expected behavior. The way to address this is within the update trigger itself, ensuring that the operations within that trigger only executes per a certain criteria such as field change.

E.g.

If(Trigger.new[i].FieldName__c != Trigger.oldMap.get(Trigger.new[i].Id).FieldName__c){
//Do Stuff
}
| improve this answer | |

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.