- Mark as New
- Bookmark
- Subscribe
- Permalink
- Email to a Friend
- Report Inappropriate Content
Documenting behavior of Z-Quotes global methods and Z-Quote triggers under test
Having documentation of what to expect when I call a global method from Apex in a unit test would be helpful. I assume that the code won't make a callout to Zuora but it would be very helpful to know what the behavior is designed to do.
Even knowing which methods have the potential to make a callout would help.
To have the best tests and coverage it is best to minimize the places that the Apex code needs to change behavior under test.
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Documenting behavior of Z-Quotes global methods and Z-Quote triggers under test
Hi Maggie,
Thank you very much for your post.
I need to discuss this internally but do you have any specific Global methods that you are looking for the documentation on?
Please let me know .
Thank you
Doyeli
If you found my answer helpful, please give me a kudo ā
Help others find answers faster by accepting my post as a solution ā
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Documenting behavior of Z-Quotes global methods and Z-Quote triggers under test
QuoteTrigger
zqu.zQuoteUtil.sendToZBilling
zqu.zQuoteUtil.renewQuote
zqu.zQuoteUtil.getChargeGroup
zqu.zQuoteUtil.getChargeGroups
zqu.zQuoteUtil.calculateChargesOnDiscountChange
zqu.zQuoteUtil.calculateChargesOnTotalChange
zqu.zQuoteUtil.calculateChargesOnQuantityChange
zqu.zQuoteUtil.addChargeGroups
zqu.zQuoteUtil.updateChargeGroups
zqu.zQuoteUtil.setSubscriptionTermChanges
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Documenting behavior of Z-Quotes global methods and Z-Quote triggers under test
Also documentation as to the uses, function, and side effects of the methods would also help.
An example is
static void recalculatePriceFields (zqu.zCharge zc, SObject sobj, String fieldName, String namespace)
in the documentation there is no description of what sobj should be nor what fieldName and namespace are.
Having that type of information readily available would simplify the effort to write code to extend Zuora on salesforce. In the past I have had to open tickets to get explanation of a method interface, but the data provided there is not visible to other developers that may be struggling.
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Documenting behavior of Z-Quotes global methods and Z-Quote triggers under test
Thank you Maggie.
I will take it to our Engineering and Documentation team.
I will update you after I discuss internally.
Thank you
Doyeli
If you found my answer helpful, please give me a kudo ā
Help others find answers faster by accepting my post as a solution ā
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Documenting behavior of Z-Quotes global methods and Z-Quote triggers under test
While researching about recalculatePriceFields(), I learned that this method is no longer used. The method was removed from the KC page.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Documenting behavior of Z-Quotes global methods and Z-Quote triggers under test
The individual behavior of the test methods when called from inside test methods might differ. For most of the global methods, we will either return null or return some mock data that we created using one of our utility classes.
- Mark as New
- Bookmark
- Subscribe
- Permalink
- Email to a Friend
- Report Inappropriate Content
Re: Documenting behavior of Z-Quotes global methods and Z-Quote triggers under test
I assume that if the global method does not do a callout then it would function the same under test as in live code.
When you return mock data that is unrelated to the parameters sent and is not documented then it is hard for us to code against and acheive our test coverage. I understand you need to have data for your test coverage when run in your org.
The trick listed here possible way to detect packaging org looks interesting to use if your code is running in your org unmanaged or in ours as managed.
I have not worked on packaged code so I do not know if this is viable.