2

I have a test class failing while validating it and its base class deployment to production. The test setup is creating several records in 2 objects (1 standard 1 custom) and inserting them as a system administrator and the test method then validates the base class is finding the correct records from the setup.

This worked fine in my Dev, Test and Stage environments. I created a new sandbox from Production, and it passes validation there as well.

After troubleshooting, I narrowed it down to the @TestSetup method (i.e. everything runs fine if I use our custom Administrator profile during test setup). Comparing the System Admin profile in Stage and Prod, I see no difference in any of its object permission for the objects I'm attempting to insert, and because it is production, I can't really just force it in and debug it there. So my question is two-fold.

  1. What else should I be looking at from a difference in permissions/settings. I validated profile permissions on the objects' fields and record types, user (deployment user) permission sets (none) and "View/Modify All" so far.
  2. Is there any method to get a debug log during deployment validation (I'm using Gearset for deployment if that makes a difference).

At this point, I'm thinking there is a custom setting being applied while creating one of the two types of records. I haven't found any custom settings or metadata that would impact these objects.

Improve this question
6
  • What error does the deployment show? What does the code for your @TestSetup method look like?
    – David Reed ♦
    Sep 10, 2018 at 20:48
  • It's a simple assertion error, not a true error. I elected to not include code as this at least seems to be environmental. If that turns out not to be true, I'll post the code.
    – Andrew Hemwall
    Sep 10, 2018 at 21:40
  • I am wondering where the diagnosis of FLS issues came from. Are you explicitly enforcing FLS in your code? In @testSetup?
    – David Reed ♦
    Sep 10, 2018 at 21:51
  • Not that I am aware. It's possible it is occurring in the testFactory class, but that class is up to date as well. I just looked at FLS to cover my bases.
    – Andrew Hemwall
    Sep 11, 2018 at 12:25
  • I made a new sandbox copy from production. And the validation passes there (i.e. no assertion failures).
    – Andrew Hemwall
    Sep 11, 2018 at 12:38

1 Answer 1

Reset to default
1

The test setup was trying to create a record with a record type that was not being found in a utility class due to trying to pass in the developer name instead of the label (name). Because it was returning null, it was using the default record type for the Gearset user, who has the System Administrator profile. That was causing the base class to be unable to find the records. While I was running the test in each environment, my profile was a custom Administrator, which just happened to have a record type default that matched what the base class needed. Hence, the test would pass. It would also pass by creating the records during the setup as that profile.

Solution: Use the label (name) for the utility class method.

Thanks for everyone's help!

Improve this answer

Not the answer you're looking for? Browse other questions tagged .