Improve trigger test deployment failure reporting when Code coverage error received

[Henzell]

I have DLRS installed in production for several months without problems. Today I deployed an inbound change set with a workflow rule and field update, and it failed due to code coverage dropping to 66%. Error message said that one of my DLRS had 1% coverage. I went to Developer Console and ran tests on my 3 DLRS triggers, and it stated 100% on Contact trigger, and 0% on my other two triggers.

[afawcett]

In the test classes they attempt to do an insert to cause the trigger to fire. Can you copy paste that line of Apex code from the Trigger and run it via Execute Antonymous.

[afawcett]

Have you added any required fields to these objects recently?

[Henzell]

No required fields added. Is this the line of code to Execute Anonymous? I am not a developer, so am treading unknown paths here.
trigger dlrs_causeview_PaymentTrigger on causeview__Payment__c
(before delete, before insert, before update, after delete, after insert, after undelete, after update)

[Henzell]

I removed the payment trigger and attempted to redeploy it. It refused to redeploy, due to the lack of code coverage. I need some hand-holding as I am out of my depth. I'm willing to pay for assistance.

[afawcett]

No its the line from the test that inserts the record, if your not a developer no worries. I worked with another person on a similar issue, i've got some ideas on how to improve the reporting when deploys fail due to code coverage. I'm a bit short of time at present due to some family commitments, but will make this a priority when i next get a window to work on it. In the meantime, is there any other Apex Triggers on the object, could these be deactivated temporarily?

[Henzell]

There are other triggers on the Payments object, but they are in managed packages, and I need them active.

[Henzell]

I downloaded your latest release, removed the Payment trigger, and tried to redeploy it - but it would not redeploy because of the code coverage error. Can you assist me with this, do I need to hire a developer, or abandon this tool? This issue is blocking a major project I am working on.

[afawcett]

This will most likely be due to one of the managed triggers throwing an error which prevents this tools trigger from firing and hence obtaining code coverage in the test. I have updated the test code used in v1.19 to report the underlying error which will hopefully help you get to the bottom of it further. I'll keep this issue open so you can report the error back to me here and I'll try to advise. The generated test attempts to insert a dummy child record (never written to the database), its likely the default field values of the child object are not acceptable to one of the managed triggers validations. In this case the auto generated code that creates the dummy record will need a developer to update it. Lets see what the error is first though...

[afawcett]

Sorry, just to confirm, in short upgrade to v1.19 and try again to see if any new information is shown that will help progress this issue.

[Henzell]

[afawcett]

So it looks like the causeview.sysLastTransUpdatePayment Apex Trigger is generating a NullPointerException when the Apex Test generated by tool attempts to insert a causeview__Payment__c record without any of the fields set. If you go to the Installed Packages page under setup you should be able to identify the package by its namespace 'causeview' from which the trigger originates from. Do you know what fields need to be populated on a Payment record to allow it to be successfully inserted? Perhaps you can try to insert one yourself through the Salesforce UI for this object?

[Henzell]

Andy,
These are the required Payment fields:
Payment Date
Amount
Status
Payment Type
Transaction ID

A transaction record is created first, then the payment is a child of the transaction.

[afawcett]

Ah thats more complicated if you need an existing record as well, hmmm. For now sadly you will need a developer to update the Apex test to create the transaction record and create a Payment record with these required fields. I do have some ideas on how to enhance this tool in the future so you can get it to generate this code (by specifying example values for the required field values to be used in the test). But this is an enhancement that i cannot commit to. Sorry about this, but i do want to set expectations accordingly and it seems unless you can find a developer you may have to take a different approach, have you looked at the Rollup Helper tool btw?

[Henzell]

Andy,
I understand the limitations of an open-source tool for which you are the
sole developer, and I appreciate what you have created.

Now that you have diagnosed the issue for me, I can either hire a developer
(Causeview will offered) or pay for Rollup Helper.

On Thu, Mar 12, 2015 at 1:50 PM, Andrew Fawcett [email protected]
wrote:

Ah thats more complicated if you need an existing record as well, hmmm.
For now sadly you will need a developer to update the Apex test to create
the transaction record and create a Payment record with these required
fields. I do have some ideas on how to enhance this tool in the future so
you can get it to generate this code (by specifying example values for the
required field values to be used in the test). But this is an enhancement
that i cannot commit to. Sorry about this, but i do want to set
expectations accordingly and it seems unless you can find a developer you
may have to take a different approach, have you looked at the Rollup Helper
tool btw?

—
Reply to this email directly or view it on GitHub
#122 (comment)
.

[afawcett]

Thanks for your understanding @Henzell. I will keep this issue open, as i have now marked it as an enhancement, this discussion will drive a means to declaratively express field values to apply when generating the test code.

[JenNelsonChicago]

Hi, Andy :-)

Hope you are well.

I am having this same issue but I do not know how to troubleshoot.

All Apex in this Org is from Managed Packages. I have tried running all Apex Tests, compiling classes and calculating coverage and it went up from 0.1% to 86% but, if I remember water cooler conversations with co-worker Devs in the past, the Managed Packages don't really count in Code Coverage for Deployment anyway, right?

Soooo...any ideas? I am on 1.19

[JenNelsonChicago]

Hi, Andy -

Version 1.19 installs as expected; however, when the Manage Child Trigger button is used to deploy the child trigger needed for the roll-up, it fails every time, always with the message that there is only 0.01% code coverage. I actually had to uninstall DLRS entirely from the Org and I think we will have to write a trigger. The org in question has 100% of its Apex all from Managed Packages so there is no ability to edit nor to alter any of the test classes to get a higher code coverage. I am not certain what else to do. V 1.16 did not throw this error but it appears to be deprecated and I did not apply any updates in between V1.16 and V1.19 so I am uncertain where the issue was introduced.

[afawcett]

That is frustrating, i have re-enabled v1.16 for now please find the URL from the README and use that. Though i would be curious to try and debug your issue further, though I'd understand if you need to press on. Can you grab a screenshot before you try again with v1.16 perhaps?

[JenNelsonChicago]

Hi, Andy -

Thanks so much for re-enabling v1.16. I am not allowed to put v1.19 back into the customer org, but I will definitely try and install it in a similarly configured Dev Org

[JenNelsonChicago]

V1.16 got me back on track - thank you! :-)

[afawcett]

Thanks, that's quite interesting, gives me one more clue to this mystery, at least i can now do a diff between changes for these two versions. Everything else you did was exactly the same yes?

[afawcett]

See related issue here, reference to my thoughts re: March 12 above.

[afawcett]

I've recently written up some shared details on the code coverage issue described in this case, please check the details here and comment at the bottom of the wiki page.

[creuman]

I ran into a similar issue and spent much longer than a developer would have to figure out the test code, but I kept plugging away out of curiosity and stubborn-ness. Similar to the original commenter, I needed a rollup from a custom Causeview object called Allocation up to Campaign, and so I needed test code to generate a bunch of things.

Here is the code that eventually worked:

Campaign camp=new Campaign(Name='Test');
insert camp;
causeview__Fund__c fund=new causeview__Fund__c();
insert fund;
Contact con=new Contact(Lastname='fred');
insert con;
causeview__Gift__c tran=new causeview__Gift__c();
tran.causeview__Constituent__c=con.Id;
insert tran;
causeview__Payment__c pay=new causeview__Payment__c();
pay.causeview__Donation__c=tran.Id;
pay.causeview__Amount__c=1;
pay.causeview__Status__c='Approved';
pay.causeview__Payment_Type__c='Cash';
insert pay;


// Force the dlrs_AllocationTrigger to be invoked, fails the test if org config or other Apex code prevents this.
SavePoint sp = Database.setSavepoint();
dlrs.RollupService.testHandler(
    new causeview__Gift_Detail__c(causeview__New_Campaign__c=camp.id,causeview__Fund__c=fund.id,causeview__Gift__c=tran.id,causeview__Payment__c=pay.id,causeview__Amount__c=1,causeview__GL_Auto_Credit_Account__c='1',causeview__GL_Auto_Debit_Account__c='1'));
Database.rollback(sp);

I wasn't able to get it to work without checking the "See All Data" box as I was getting an CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, execution of AfterInsert error. I would love to know how to get around that part.

I also get a Too many query rows error when I try to calculate everything, but if I filter to a specific Campaign, it will calculate. None of my Campaigns have more than 50,000 Allocations, but there are definitely more than 50k overall. Not sure what to do about that either, but I'm really glad I got the trigger to deploy.

PS this tool is my most favorite thing ever. Thank you!

[JenNelsonChicago]

Thanks, @creuman for the additional example!

P.S. I agree on this being a favorite tool. :-)

[SteffanH]

@creuman , thanks for posting the workaround for objects that are generating validation errors.

I'm currently trying to implement this workaround for a (managed) object that is causing a similar issue, unfortunately, when editing the test class in the Force.com Developer console, I'm stuck with the following error message:

Package Visibility: Method is not visible: dlrs.RollupService.testHandler(SObject)

Any suggestions on what i might be doing wrong ?

[creuman]

@SteffanH you shouldn't need to edit the test class in the Developer console, just put the snippet of test code into the Test Code field right on your DLRS record. If you have an older version of the DRLS package, the field might not be available, but if you upgrade, v1.22 has it.

[SteffanH]

Hmmm, upgrading the package hadn't added the fields to the Page Layout, thanks !

[afawcett]

Ok, i'm going to close this one out, i think i did keep it open as an enhancement in the rather optimistic view that i could devise some declarative means to fulfill custom test code requirements. Plus the core issue reported here was resolved.