I have a batch class and in the constructor of the class, I have a query in which it queries for a Queue.


public BatchClass(){
final String QUEUE_NAME = GlobalPropertyCache.getValue('DOCUMENT_QUEUE_NAME');
queue = [SELECT QueueId
    FROM QueueSobject
    WHERE Queue.Name =: QUEUE_NAME
    LIMIT 1];

This code works fine but the issue is creating tests. GlobalPropertyCache is basically a custom metadata. QUEUE_NAME has a value of the name of a queue in our environment. That queue has been deleted hence the query is now failing and test being broke. I don't want to use live data in our test. But the bizzare thing is that i am creating a dummy value in the test class yet the actual code is still using the value in the environment..

  • Can you show us how you are providing a dummy value in the test class? When you say "GlobalPropertyCache is basically a custom metadata", do you mean literally that GlobalPropertyCache queries a Custom Metadata Type?
    – David Reed
    Jan 18, 2019 at 14:29

1 Answer 1


It's not exactly clear what GlobalPropertyCache is, and it appears that you have some misconceptions about unit tests. You've kinda mangled some terminology here.

There's Custom Settings, and also Custom Metadata Types. The answer is likely different depending on which one of those you're actually using.

Based on the getValue() in your code, I think it's safe to say that you're using a Custom Setting (and a List Custom Setting, at that).

In your unit test, your "real" data hasn't been deleted. It's just not made available to you, with the exception of a few key objects.

From Isolation of Test Data From Organization Data In Unit Tests

Starting with Apex code saved using Salesforce API version 24.0 and later, test methods don’t have access by default to pre-existing data in the organization, such as standard objects, custom objects, and custom settings data, and can only access data that they create. However, objects that are used to manage your organization or metadata objects can still be accessed in your tests such as:

  • User
  • Profile
  • Organization
  • AsyncApexJob
  • CronTrigger
  • RecordType
  • ApexClass
  • ApexTrigger
  • ApexComponent
  • ApexPage

Further, from experience, Custom Metadata Type data is available in unit tests, while Custom Setting data is not. It's hard to guess at what might be going on when you say that you're getting real data from your custom setting (even harder because you haven't included your unit test).

At any rate, like most things in testing on the Salesforce platform, there is very little difference between writing code for "real" and writing code for a test.

You can perform DML to manipulate the data stored in Custom Settings

MyCustomSetting__c testCustomSetting = new MyCustomSetting__c(
    Name = 'testValue',
    Custom_Setting_Custom_Field__c = 'very custom, wow!'

insert testCustomSetting;

MyCustomSetting__c retrievedCustomSetting = MyCustomSetting.getValue('testValue');
retrievedCustomSetting.Custom_Setting_Custom_Field__c = 'much custom, amaze!';
update retrievedCustomSetting;

At this point, I hope it goes without saying that you'll need to create a queue to match your custom setting value as well.

You might consider looking into dependency injection (DI) here, which generally makes testing easier. The gist of DI is that instead of querying for or constructing data that a particular class needs to be able to run, you do the querying/construction outside of the class and pass it in (via constructor, method parameters, setting class variables, etc...)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .