Friday, November 09, 2018

Experiment : Test.loadData . Upload test data with static resources

Test.loadData is a method that enables us to create test data by using Static Resource. This was released quite sometimes but I haven't use it intensively. I experienced using it to load data in bulk because I wanted to test governor limit.

Recently we plan to use this on our project instead of using test data factory.Pushing test data using csv files are much easier compare to code insertion and define relationship.

I did some simple proof of concept using code below :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
@isTest
private class DataUtil {
    static testmethod void testLoadData() {
        // Load the test accounts from the static resource
        List<sObject> ls = Test.loadData(Account.sObjectType, 'AccountData');
        // Verify that all 3 test accounts were created
        System.assert(ls.size() == 3);

        // Get first test account
        Account a1 = (Account)ls[0];
        String acctName = a1.Name;
        System.debug(acctName);
        
        a1.Name ='New Name';
        
        update a1;
        
        Account a2 =[Select Id,Name from Account Where Name ='New Name'];
        
  //check if account get updated
        system.debug('After update a2 '+ a2.Name);
        
        Contact contact =new Contact (FirstName='TestContact',LastName='Lasting',AccountId=a2.Id);
        insert contact;
        
        Contact contact1=[select FirstName from Contact Where AccountId=:a2.Id];
        
        //yes , able to create contact on the account
        system.debug('After update contact1'+ contact1.FirstName);
        
        delete a2;
        
        List<Account> listAccount=[select Id from Account where Name='New Name'];
        //yes, able to delete
        system.assertEquals(0,listAccount.size());

    }
}

1. Can I update the record that I have loaded?
    Yes
2. Can I create child to the record that I have loaded?
     Yes
3. Can I delete the record that I have loaded?
    Yes.
4. Will insert trigger cover using Test.loadData?
    Yes, but validation rules is still applied.
5. Can I define relationship for example between Account, Opportunity and Contact?
     Yes you can.You can define it with mockup id in the column like below

When defining relationship, make sure that you run loadData method in proper order : master first then follow by child.In the example below, load Account first then Opportunity then Contact.

1
2
3
4
        // Load the test data  from the static resource in proper order
        List<sObject> lstAccount = Test.loadData(Account.sObjectType, 'AccountData');
  List<SObject> lstOpportunity = Test.loadData(Opportunity.sObjectType,'OpportunityData');
        List<SObject> lstContact = Test.loadData(Contact.sObjectType,'ContactData');

Some useful links to check out  :


Hope this help.

Tuesday, October 30, 2018

Process Builder is not fired when field update is called from Approval Process

Scenario
In Final Approvals section ; in Approval Process we have field update to update Status field. In Process Builder , we have some action that need to be done when Status field is updated in Approval Process.However this process builder is not fired.

Solution
To handle this, in Field Update in Approval Process , check Re-evaluated Workflow Rules after Field Change as picture below.



What happen if field updated from Approval Process.
  1. Workflow - does not fires untill Re-evaluate workflow checkbox is ticked on your field update
  2. Process Builder - does not fires untill Re-evaluate workflow checkbox is ticked on your field update
  3. Trigger - will fire if conditions are matched

This is explained in article here .

Field Updates That Re-evaluate Workflow Rules

If Re-evaluate Workflow Rules After Field Change is enabled for a field update action, Salesforce re-evaluates all workflow rules on the object if the field update results in a change to the value of the field.
  • If the field update changes the field’s value, all workflow rules on the associated object are re-evaluated. Any workflow rules whose criteria are met as a result of the field update will be triggered.
  • If any of the triggered workflow rules result in another field update that’s also enabled for workflow rule re-evaluation, a domino effect occurs, and more workflow rules can be re-evaluated as a result of the newly-triggered field update. This cascade of workflow rule re-evaluation and triggering can happen up to five times after the initial field update that started it.
  • Make sure that your workflow rules aren’t set up to create recursive loops. For example, if a field update for Rule1 triggers Rule2, and a field update for Rule2 triggers Rule1, the recursive triggers may cause your organization to exceed its limit for workflow time triggers per hour.
  • In a batch update, workflow is only retriggered on the entities where there is a change.
  • Only workflow rules on the same object as the initial field update will be re-evaluated and triggered.
  • Only workflow rules that didn’t fire before will be retriggered.
  • Cross-object workflow rules aren’t candidates for re-evaluation.
  • Cross-object field updates that cause a field value to change don’t trigger workflow rule re-evaluation on the associated object.
  • An approval process can specify a field update action that reevaluates workflow rules for the updated object. If, however, the re-evaluated workflow rules include a cross-object field update, those cross-object field updates are ignored.
  • Time-dependent actions aren't executed for a reevaluated workflow rule in the following situations:
    • The reevaluated workflow rule’s immediate actions cause the record to no longer meet the workflow rule criteria.
    • An Apex after trigger that is executed as a result of a workflow or approvals action causes the record to no longer meet the workflow rule criteria.

Discussion about this can be found here .