Mocking Triggers across multiple objects/operations during test

[mikbranchaud]

I think I see how your trigger test class mocks the trigger configuration mdt query locator so that a test method can anticipate one or more mock config records being narrowly executed for a single object/event. Could you comment on what the testing strategy would be if I am using a test data factory that creates multiple objects, each of which might have triggers on multiple events all in one command?

For instance, lets say I have a TestDataFactory method called createComplexCase which will spin out x cases, each related to 2 contacts each of which has some master detail records too. In my production environment, I would have before update, before insert, after update and after insert trigger handlers on Case and Contact. Lets say the Before Insert trigger on Case and the Before Insert trigger on Contact supports on functional feature, call it feature A, and the other trigger handlers support some unrelated features. So I have a test class FeatureA_Test which calls the TestDataFactory in a testSetup, but I dont want the triggers for FeatureB, C and D to execute. So I want to mock the config records from the FeatureA_Test testSetup method.

My understanding though is that the query locator is specific to an object type and event so I could mock the Case Before Insert config record by setting rflib_TriggerManager.QUERY_LOCATOR to a list of rflib_Trigger_Configuration__mdt I create. But when the TestDataFactory creates the contacts, the trigger handler I want to test on contact would not execute because I can only mock one object/type at a time. Is my understanding correct?

I think the answer is for a test class to pass a map of rflib_Trigger_Configuration__mdt indexed by object/event to the testdatafactory and for the testdatafactory to mock the config records dynamically before each DML statement. This would handle multiple objects but not multiple events. Thoughts?

[mikbranchaud]

Note, I thought about using feature switches to accomplish this, but our Org is not currently using your feature switches component. The thing I am not sure of is whether I can mock the feature switch setting in a test class as I do not see an interface for feature switches that would allow turning off unrelated features during a test run?

[j-fischer]

Hi @mikbranchaud ,

First of all, apologies for the delayed response, I haven't had much time to check the project lately.

Now, regarding your comment/question, the QUERY_LOCATOR is still the right place to do it. But I did not have the need to handle such a complicated case like yours yet, hence the implementation was a bit more simplistic.

Having said that, take a look at commit e0bca5c where I refactored the class to allow for a Map to be passed as a constructor argument. Map<String, Map<String, List<rflib_Trigger_Configuration__mdt>>>

In this case, the first string is the object, the second string in the inner Map represents the trigger operation type. I believe that should give you the flexibility you need to orchestrate your test classes.

public rflib_MockTriggerConfigQueryLocator(Map<String, Map<String, List<rflib_Trigger_Configuration__mdt>>> configRecords) {
    this.configRecords = configRecords;
}

Please let me know if that did not the trick.

Cheers,
Johannes

[j-fischer]

The updated class was release in RFLIB-TF v1.3.0