How to mock, inject or otherwise make Custom Metadata available to apex tests

Question

I have some code which relies on some Custom Metadata records to exist, but I don't want my tests to depend on real records in the org. How can I either inject or mock custom metadata records into the class?

Here's a psudocode example of what the code is doing:

global static String fetchCalloutPath(String endpointName){
        endpoint__mdt endpointMDT = endpoint__mdt.getInstance(endpointName);
        if(endpointMDT == null){
            throw new NoEndpointMetadataFoundException('Unable to find a endpoint__mdt record for endpoint "' + endpointName + '"');
        }
        Credential_Map__mdt credentialMDT = getCredential(endpointMDT.APIName__c);

        String calloutPath = 'callout:' + credentialMDT.Named_Credential__c + endpointMDT.Value__c;
        return calloutPath;
}

private static Credential_Map__mdt getCredential(String apiName){
    return [
        SELECT Named_Credential__c
        FROM Credential_Map__mdt
        WHERE APIName__c = :apiName
    ];
}

So in order to get a Credential_Map__mdt record I must first get an endpoint__mdt record.

I want to be able to reliably test and therefore mock or inject the metadata records, but I'm having a hard time understanding how best to achieve this, especially with there being a getInstance call involved. I'm thinking I might have to change that to a SOQL query in order to actually get this working but I'm hoping someone might have a solution for this (if so I can use this method elsewhere in the org). Also if I have to create interfaces or mock classes, will I need 2 due to the different metadata types involved? I'm hoping there might be some generic solution I could use elsewhere in the org.

Hoping for some guidance. Thanks!

Answer 1

Dependency Injection is dead simple, and query injection is a great example of how to generalize that approach across your codebase. It's as simple as writing the following class.

public inherited sharing class Query
{
    public static List<SObject> records(List<SObject> records)
    {
        return instance.passThrough(records);
    }
    
    @TestVisible static void setMock(Service mock) { instance = mock; }
    static Service instance = new Service();
    public virtual class Service
    {
        protected List<SObject> passThrough(List<SObject> records)
        {
            return records;
        }
    }
}

Now anywhere you would query your metadata, wrap that call in Query.records.

public with sharing class MyService
{
    public static void myMethod(/*parameters*/)
    {
        List<My_Metadata__mdt> metadata = Query.records([
            SELECT ... FROM My_Metadata__mdt WHERE ...
        ]);
    }
}

The live implementation only needs to change very slightly, as above. It's a very safe change to make everywhere, as this logic behaves exactly the same except for in your tests. Just make sure you keep the API Version up to date. Your test can then setMock with a custom instance you set your own data store on.

@IsTest
class MyServiceTest
{
    @IsTest static void testMyMethod()
    {
        List<My_Metadata__mdt> metadata = new List<My_Metadata>();
        // populate as desired
        Query.setMock(new QueryMock(metadata));
        
        Test.startTest();
            MyService.myMethod();
        Test.stopTest();
        
        // assertions
    }
    class QueryMock extends Query.Service
    {
        final List<SObject> records;
        QueryMock(List<SObject> records)
        {
            this.records = records;
        }
        protected override List<SObject> passThrough(List<SObject> toIgnore)
        {
            return records;
        }
    }
}

I would make the QueryMock a public test utility, since you will have a large number of identical implementations where the only difference is the records parameter, which you pass in.

You can take this example and adapt it to be much more specific to your situation, rather than writing a library available for your whole codebase. Just make the inner class a part of your current top level service instead.