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.

closed as off-topic by David Reed, glls, battery.cord, Mohith Shrivastava, Oleksandr Berehovskyi Sep 16 '18 at 16:36

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions on problems in code you've written must describe the specific problem and include valid code to reproduce it. For help writing short, self-contained syntactically-valid examples, see: SSCCE.org" – David Reed, glls, battery.cord, Mohith Shrivastava, Oleksandr Berehovskyi
If this question can be reworded to fit the rules in the help center, please edit the question.

  • What error does the deployment show? What does the code for your @TestSetup method look like? – David Reed Sep 10 '18 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 '18 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 '18 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 '18 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 '18 at 12:38
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!

Not the answer you're looking for? Browse other questions tagged or ask your own question.