How to write test class for metadata which is dependent on post deployment steps?

Question

We have a functionality in our managed package which is dependent on Knowledge__kav. So we have an object Test which has a lookup on Knowledge object. And a custom permission CS1 which is given to user to access Test

Now, as we cannot add any dependency to knowledge in our managed package, because it fails packaging and deployment (bug or a miss from salesforce end), we have removed lookup from Test and removed CS1 from our package and created an unmanaged package, which does adds the lookup to Test and also adds the CS1.

The functionality related to Knowledge only works after the unmanaged package has been installed.

ISSUE: How do we write test class for this in our managed package. We have used SObject approach to determine whether Test as a lookup as Knowledge, if not we don't proceed and show an error message, but if has we have a lot of apex code. This needs to be covered with Unit Test. How do we cover this from managed package, also how to write a permission based test, when the PS is part of unmanaged package.

Code Snippet for Apex logic:

public static SObjectField getSObjectField(String sObjectName, String fieldName) {
    SObjectType sObjectType = getSObjectType(sObjectName);

    if (!sObjectFieldsByObjectNames.containsKey(sObjectName)) {
        sObjectFieldsByObjectNames.put(
            sObjectName,
            sObjectType.getDescribe().fields.getMap()
        );
    }
    return sObjectFieldsByObjectNames.get(sObjectName).get(fieldName);
}

SObjectField knowledgeOnTest = SObjectService.getSObjectField('Test__c', 'Knowledge__c');
if (knowledgeOnTest != null) {
    // run logic
}

Answer 1

You need to adopt an appropriate unit test mocking strategy where you avoid use of static methods, have dependency injection and use mockable objects. Consider something like the fflib apex mocks and some form of dependency injection.

By structuring your code appropriately, e.g. with separate "selectors" for queries and "mutators" for DML operations, you can mock out various parts that would cause you trouble (via virtual methods and test-specific specializations that replace those methods or via the StubProvider, depending on your code structure). You may also find the SObject Fabricator of use here.

It is possible to have parts of the metadata on the release org for your 1GP that are themselves not part of the managed package, though it's hard to make sure it stays that way with automatic dependency processing. This might however help you here. For 2GPs Salesforce recently piloted the concept of a package directory that is used during version creation test execution but that is, itself, not part of the package, which would also likely help in this case if you were on 2GP.

Yeah, this is a very high-level answer but hopefully the various referenced mechanisms are of use.