Field level security pain in Apex tests when using packaging 2

Question

In line with current security standards, we use with security_enforced extensively in our code. When doing CI (Continuous Integration) builds or working interactively we use sfdx force:user:permset:assign to assign permission sets that grant the field level access so the Apex tests pass. And when our product is installed no tests are run so no problem there.

But packaging 2 creates the packaging org on the fly and runs the Apex tests with no hook point to do any org preparation. So what strategy works to get the right field level permissions set?

• Duplicate all the permissions in the Admin.profile-meta.xml?
  • This assumes that the packaging process does use that profile. Does it?
  • And that the Admin.profile-meta.xml is applied in the packaging org. Is it?
• Assign the permission sets programatically in the @TestSetup method of every test? But that then has MIXED_DML_OPERATION challenges.
• Modify the product code to not do security checks when tests are running. (Yuk.)
• Better approaches?

We are getting test failures on packaging related to custom fields we add to the Event object and are trying to figure out why.

Answer 1

You can specify permission sets to use for version creation. A snippet is provided in the documentation.

"packageDirectories": [
    {
        "path": "force-app",
        "package": "TV_unl", 
        "versionName": "ver 0.1",
        "versionNumber": "0.1.0.NEXT",
        "default": true, 
        "unpackagedMetadata": {
            "path": "my-unpackaged-directory"
        },
        "apexTestAccess": {
               "permissionSets": [
                   "Permission_Set_1",
                   "Permission_Set_2"
               ],
               "permissionSetLicenses": [
                   "SalesConsoleUser"
               ]
           }

    }, 
    {
        "path": "my-unpackaged-directory",
        "default": false
    }
]

This means that you won't need to write permissions into your tests, you won't need to intentionally dumb down security and risk false security flags in Checkmarx, and you'll eliminate most of your challenges when building new versions of your packages.