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:
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!'
MyCustomSetting__c retrievedCustomSetting = MyCustomSetting.getValue('testValue');
retrievedCustomSetting.Custom_Setting_Custom_Field__c = 'much custom, amaze!';
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...)