There is possible hack to have different values in tests than it is in organization.

This is a good way to have your tests always stable and 100% covered even if custom metadata is changed or removed on your organization.

For this hack you just need to put query for custom metadata into separate property which should be settable for unit tests.

@testVisible static List<Custom_Metadata__mdt> customMetadata { get { if ( customMetadata == null ) customMetadata = [ SELECT All_Needed_Custom_Fields__c FROM Custom_Metadata__mdt ]; return customMetadata; } set; } Then you can use JSON.deserialize method to setup these metadata records. This method allows you to overcome 'field is not writable' error.

Example of code you could use is the following:

CustomClass.customMetadata = (List<Custom_Metadata__mdt>) JSON.deserialize( '{"All_Needed_Custom_Fields__c ":"dummyValue"}', List<Custom_Metadata__mdt>.class ) Hopefully this hack will be available in the future as well, since this is the only way to get coverage for code.

This is based on the comment on Idea Exchangeenter link description here

There is possible hack to have different values in tests than it is in organization.

This is a good way to have your tests always stable and 100% covered even if custom metadata is changed or removed on your organization.

For this hack you just need to put query for custom metadata into separate property which should be settable for unit tests.

@testVisible static List<Custom_Metadata__mdt> customMetadata { 
    get {
        if ( customMetadata == null )
            customMetadata = [ SELECT All_Needed_Custom_Fields__c FROM Custom_Metadata__mdt ]; 
        return customMetadata;
    } set; }

Then you can use JSON.deserialize method to setup these metadata records. This method allows you to overcome 'field is not writable' error.

Example of code you could use is the following:

CustomClass.customMetadata  = (List<Custom_Metadata__mdt>) JSON.deserialize( '{"All_Needed_Custom_Fields__c ":"dummyValue"}', List<Custom_Metadata__mdt>.class );

Hopefully this hack will be available in the future as well, since this is the only way to get coverage for code.

This is based on the comment on Idea Exchange - Custom MetaData Types need APEX methods to access/update