1

Hoping someone can help with the following issue I am currently experiencing.

I have created a new process via the process builder that sets the Contact owner to be the same as the Account Owner on creation of the Contact. 

Now, when I 'run all tests' during deployment or in Eclipse IDE I run into test failures. The affected classes all point to lines in the code wherever a Contact needs to be created in the test class.

Is there anything I can introduce into the test classes to prevent them from failing? or is there something I can introduce to the code to prevent the process from firing when a Contact is being created for code coverage?

To ensure successful deployments I have to deactivate this process and reactivate afterwards.. just so it will upload to Production. Less than ideal.  I also created this process to replace an old Apex trigger that did the same job but very unreliably. Now I'm starting to regret archiving this trigger given the interference the process is having on the existing test classes in our Salesforce org. 

Any advice/tips/experiences to share on resolving this kind of issue would be greatly appreciated!

Also going to include an error message and the lines of code throwing this error below.

error message:

'System.DmlException: Insert failed. First exception on row 0; first error: UNKNOWN_EXCEPTION, We can't save this record because the “Set Contact Owner to Org Owner on Creation” process failed. Give your Salesforce admin these details. An unhandled fault has occurred in this flow
An unhandled fault has occurred while processing the flow. Please contact your system administrator for more information.: []'

Class.MyProfilePageControllerTest.testSave: line 35, column 1

line 32 to 35, column 1: 

  Contact c = new Contact();
            c.LastName = 'TestContact';
            c.mailingcountry = 'Ireland';
            insert c;

Thanks!

|improve this question
  • 1
    I am seeing that you are creating a contact without an Account. It could be the reason that your process builder is failed. Do you try to create an Account and set the AccountID in the Contact? If it is the issue you should change the process builder to avoid this issue when AccountID is null – m Peixoto May 13 at 14:10
  • Are you suggesting I would have to have an account created in the test class so it won't fail? That could explain it. As for the process when it runs in production it does not fail because our Users create contacts on Accounts directly or via lead convert to an Account. – Gillian O Leary May 13 at 14:12
  • It is always best practice to write unit tests that are self-sufficient (in data terms), avoiding the use of the seeAllData=true attribute on the IsTest annotation. Note that, even then, validation rules, process builder flows, triggers or other meta data added by other parties can break your tests. The only real option you have is to fix the tests so their data is compatible with these additional definitions. – Phil W May 13 at 14:30
  • Hi @PhilW Thanks for the tips! we dont have the seeAllData=true attribute. It seems that I might need to create an account and a User in the same method the test Contact was created for the test class. Maybe then when the process fires it has dummy data to work with? The process might just need the presence of one User for Owner Id and one Account with that Owner ID and then the Contact might get created as the process will be able to run OK in the Test class? Im going to try it and see if it works. Just hoping someone else who may have experienced this before can share how they resolve it! – Gillian O Leary May 13 at 14:45
  • We have repeatedly suffered similar issues when admins configure extra validation or processes that mean we can no longer deploy change sets to production since all our tests now fail. The only recourse is to update the tests to make them conform with the new requirements (by ensuring the test data is valid against the new stuff added by the admins). It is a very frustrating situation because it is outside the developers' control but it is the developers who have to sort it out. – Phil W May 13 at 15:01
1

We have repeatedly suffered similar issues when admins configure extra validation or processes that mean we can no longer deploy change sets to production since (some or all) our tests now fail.

The only recourse is to update the tests to make them conform with the full set of requirements on production (by ensuring the test data is valid against the new stuff added by the admins). It is a very frustrating situation because it is outside the developers' control but it is the developers who have to sort it out.

|improve this answer
0

There are four approaches to avoiding this issue

  1. Update the testmethods to include the necessary data that the PBs require (Phil W's suggestion)
  2. Update the PBs to do a better job of testing for the absence of related objects so they don't blow up
  3. Gate the PBs with a custom setting that you enable in your testmethods to turn off the PBs for those testmethods where you are having this issue
  4. Rework your testmethods and code to use dependency injection and mocking. This is well covered in Force.com Enterprise Architecture 2nd Edition by Andrew Fawcett, now VP at SFDC. This approach means you can avoid doing DML in your testmethods and hence the PBs won't execute. It is great for unit testing.

In our org, we use a combination of 1 (some), 2 (definitely) and 4 (most definitely)

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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