I suppose this is more of a general programming question than a strictly Salesforce question.

I have a trigger which clones / creates new record when criteria fits the match:

trigger cloneObj on Obj__c (before update) {
     List<Obj__c> myList = new List<Obj__c>();     
     for(Obj__c a: trigger.new) {
        if (
        a.criteria__1__c != Null &&
        a.criteria__1__c == Null &&
        a.RecordTypeId==CustomRT.Id &&
        a.Deal_Done_Not__c == 'Deal Done (Existing client / Existing meter)' ||
        a.Deal_Done_Not__c == 'Deal Done (New Product, New Client)' ||
        a.Deal_Done_NOt__c == 'Deal Done (New Product, Existing Client)' ))
        a.Clone_Date_Time_Stamp__c = System.Now();        
        Obj__c b = new Obj__c();                
        b.Name = a.Name; 
        b.Site_name__c = a.Site_name__c;
        b.Contract_arranged_under_the_name_of__c = a.Winning_Contract_Arranged_Under_Name_of__c;
        b.Account__c = a.Account__c; 
        b.Linked_Basket2__c = a.Linked_Basket2__c;
        b.Linked_Monitor_Line__c = a.Linked_Monitor_Line__c;

As you can see such code is not very maintainable - whenever I need to add a field I will have to rewrite a testing class, deploy, etc.

I was once told that it's nice to have maintenance tables (or probably also called configuration table?). Now in this way the pseudocode would look more like:

        configuration = [Select Criteria__c, Fields_to_clone__c from Maintenance_table__c where process_name__c="ProductClone"];
        if (
        // Retrieve the record using SOQL and use clone function or just devise a way use b.* = a.*
        object__c recordToClone = [select configuration.Fields_to_clone__c from object__c];
        object__c newRecord = recordToClone.clone(false, false);
        insert newRecord; }

You probably got the point.

The question is how one would test their code written in such fashion?



You can access the fields in an object dynamically via describe. You can even get a map of all of an object's fields - see here.

That might be able to handle the basics of letting your code adapt to new fields without needing an update. You will still need to add tests where there are specific rules you need to enforce around a field's values.

| improve this answer | |

You can create queries via strings and execute them as dynamic SOQL and access SObject fields using the map-like get and put methods. You can use custom settings to store the configuration information.

If you choose to go that route in your product code, you can keep your tests simple by using pre-existing objects and fields (e.g. Account or a test custom object you create) in your tests and just supplying those field names to your dynamic code via the custom settings.

| 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.