Best Practice on Salesforce Refresh Integration

Question

This is a question on best practices for Salesforce orgs that have a lot of data dependent processes (i.e. dev boxes need a lot of standard records inserted post-refresh ).

I have this scenario at my current place of employment. I have built an integration between a full production copy, and dev sandboxes via APEX, connected apps, auth providers, and Named Credentials. This has proven to be a good use case for our team, and now I am at the point of writing test classes.

Problem:

Dev sandboxes are heavily dependent on record data (not to be confused with meta-data) for having a working developer environment. A standard example would be community based processes that need users activated in order to test the environment, but those users may have a complicated application process that needs to be configured before users can be added.

Solution:

Write a simple set of GET methods between Saleforce Dev box and Salesforce Fullbox data, and avoid writing test classes by commenting out the code you want to run on refresh. The test class would look like this:

@isTest
public class coverCommentedOutCode{
    @IsTest
    private static void testAsync() {
        AsyncRefreshProccess asyncTest = new AsyncRefreshProccess();
    }
}

Justification of Solution (i.e. why avoiding full test classes in this situation is safer and ironically better for Prod).

The controversial part here is the deployment of commented code. However, given that this code should never touch other production code and should only be run in sandbox environments this solution makes sense to me. The developers who want to run this code, would have to uncomment the code before it could be run in their dev sandbox. This adds an extra step that only devs on our team would know, but more importantly it prevents significant work for test classes to be run which would make the code theoretically possible to run in production. Does the stackexchange community see anything wrong with my reasoning here?

Thanks in advance!

Answer 1

It is kind of bad practice to start making exceptions for code that runs only in a sandbox context. Since you are relying on this code to execute correctly over time, why not write testmethods to assure yourself that on each regression test run, that the code does what you want.

If you need to make sure this code never runs in PROD, gate the code by testing on the organization context

Here's a utility property that is useful

public static Boolean isSandbox {
        get {
            if (isSandbox == null) {
                isSandbox = [SELECT IsSandbox FROM Organization Limit 1].IsSandbox;
            }
            return isSandbox;
        }
        set;
    }

You can use this in real code or in testmethods

if (!Util.isSandbox) {return;}  // don't run/permit some code if in PROD

or ..

Util.isSandbox = true;  // coerce test to always assume it is running in sandbox

Util.isSandbox = false; //coerce test to assume it is running in PROD