Apex test class can't have Production profile in Scratch Org

Question

I have a test class like this:

    Account acc = new Account(name='testAcc');
    Insert acc;

    Contact con = new Contact(LastName='TestContact', AccountId=acc.Id);
    Insert con;

    Id p = [SELECT Id FROM Profile WHERE Name = 'myCustomProfile' Limit 1].Id;
    

    User runas = new User(Alias = 'testUser', Email='[email protected]', 
    EmailEncodingKey='UTF-8', LastName='TestUser', LanguageLocaleKey='en_US', LocaleSidKey='en_US', 
    Profileid = p, Country='United States', IsActive=true, BU_Name__c = 'US', CompanyName = 'testCompany',
    ContactId = con.Id, TimeZoneSidKey='America/Los_Angeles', Username='[email protected]');

    Insert runas;
    
    System.runAs(runas){
        Test.startTest();
        ......
        Test.stopTest();
    }  

However, I do not have 'myCustomProfile' in my scratch org if I run this:

sfdx force:org:create --setdefaultusername --definitionfile config/project-scratch-def.json --wait 10 --durationdays 7

With this project-scratch-def.json file:

{
  "orgName": "myOrgName",
  "edition": "Enterprise",
  "hasSampleData": "true"
}

This caused the unit test of my unlocked package in the scratch org to fail. I guess there is a step that I might have missed. Or is there anything I can do to prevent this?

Answer 1

You can include the profile in your Unlocked Package; it works the same as including any other type of metadata, just retrieve it and commit it to your repo.

sfdx force:source:retrieve -u sandbox-or-prod -m Profile:myCustomProfile

P.S. If you're still using Profiles like this, it might be time to look in to migrating to Permission Sets instead. They are far easier to use in unit tests and even have a SFDX CLI command to assign Permission Sets easily to your Scratch Org users.

P.P.S. An Unlocked Package doesn't actually create a Scratch Org. It's a temporary org that's used only for the upload/validation process, and is not tied to any existing created sandbox. This process is nearly identical to the Managed Package upload process, except we're allowed to specify dependencies manually, while Classic Managed Packages do this automatically.