#73: Inject namespace using string replacements.

[zenibako]

Avoid code duplication of ApexMockeryOverview and StubBuilderImpl by using Salesforce CLI's string replacement functionality to replace namespace. with the value of the SF_NAMESPACE_DOT environment variable.

Description

I replaced mockery. with namespace. where it was hard-coded into Apex, and added the string replacements to the sfdx-project.json config file. This format for the replacement string should be more friendly to linters than alternatives like %%%NAMESPACE_DOT%%% (which is what CumulusCI uses).

Because I set the allowUnsetEnvVariable property to true, namespace. will be cleared if the SF_NAMESPACE_DOT environment variable isn't set, which allows the variable to effectively act as a toggle for namespace/non-namespace testing. This should enable a less-invasive developer experience overall while still allowing for namespace testing.

Motivation and Context

#73

How Has This Been Tested?

I had some issues actually testing this in a namespace (scratch org wasn't able to be created even after adding my own namespace to the config). Apologies for not testing this in more depth prior to committing...perhaps it's fine since it will need the main repo's secrets to properly test packaging anyways. Please feel free to push back or suggest fixes; I might try again later.

I was able to text the conversion process itself by following the Test String Replacements process specified in the docs, which verified that the string replacements themselves are successful.

[scolladon]

question: SF_NAMESPACE_DOT should be used then in the github actions right ?

We should remove then this githubaction
And only use this one:

• It should take a parameter a boolean "namespace". When namespace is true it should set the SF_NAMESPACE_DOT with the value mockery., else it should set it with empty string
• this github action should be modified to call the only one action twice with the "namespace" boolean true for validate-namespace-compatibility step and false for validate-package-version

Something like that ?

[zenibako]

That's exactly it. It should also give people the opportunity to use their own namespace if they want to fork the package (since tests in their repository will fail if it is locked to mockery).

[scolladon]

I'll try to contribute here soon (don't know when yet) !

[scolladon]

Not sure when I'll be able to work on this @zenibako

Feel free to start the work from this discussion 😁

[anuragoyar]

Potential Risks and Suggestions:

File: force-app/recipes/classes/ApexMockeryOverview.cls
Code Snippet: namespace.Mock deliveryServiceMock = namespace.Mock.forType(DeliveryService.class, new StubBuilderImpl());
Comment: The code is being modified to use a namespace prefix pattern with a replacement strategy. Ensure that the SF_NAMESPACE_DOT environment variable is properly set in all deployment environments, or the code will use the literal "namespace." text which would cause runtime errors.

File: force-app/test/namespace/classes/ApexMockeryOverview.cls
Code Snippet: (Entire file being deleted)
Comment: The test class is being completely removed. Verify that test coverage for the functionality is maintained through other test classes to ensure the 75% code coverage requirement for deployments is met.

File: sfdx-project.json
Code Snippet: "replacements": [ { "glob": "force-app/recipes/**/*.cls", "stringToReplace": "namespace.", "replaceWithEnv": "SF_NAMESPACE_DOT", "allowUnsetEnvVariable": true } ]
Comment: The replacement strategy allows for an unset environment variable with "allowUnsetEnvVariable": true. This means if SF_NAMESPACE_DOT is not set, the namespace prefix will be removed entirely. Ensure this is the intended behavior, as it changes how the code interacts with the mocking framework.

Summary:

This PR implements a namespace handling strategy for the Apex Mockery framework. The key changes are:

1. Refactoring the code in ApexMockeryOverview.cls to use a namespace prefix pattern (namespace.) that will be replaced during deployment based on environment variables.

2. Updating StubBuilderImpl.cls to implement the namespaced interface.

3. Removing a duplicate test class from the force-app/test/namespace/classes/ directory, likely because the functionality is now covered by the updated class in the recipes directory.

4. Adding a replacement configuration in sfdx-project.json to handle namespace substitution during deployment.

The approach is generally sound for managing namespaced and non-namespaced versions of the code. However, there are potential risks if the environment variable is not properly set in all environments. The deletion of the test class should be verified to ensure test coverage is maintained.

This change appears suitable for production deployment as long as the environment variable handling is properly configured in all target environments and test coverage is maintained. The use of the replacement strategy is a common pattern for managing namespaced code in Salesforce packages.