search

SFDO-Community / declarative-lookup-rollup-summaries

Declarative Lookup Rollup Summaries (DLRS) is a community built and maintained Salesforce application that allows you to create cross object roll-ups declaratively - no code! For install instructions and documentation, visit our website https://sfdo-community-sprints.github.io/DLRS-Documentation/
https://sfdo-community-sprints.github.io/DLRS-Documentation/
BSD 3-Clause "New" or "Revised" License
696 stars 238 forks source link

Thoughts on Solving the Code Coverage Issue on Auto Gen Trigger Tests via onDelete or Flow? #332

Open rodriguezartav opened 8 years ago

rodriguezartav commented 8 years ago

Hi @afawcett

Working on a similar problem and standing on your shoulders here trying to solve the same problem code free for creating auto-generated tests for triggers

What about adding onDelete and (SeeAllData=true) - then try to cover the trigger on delete with a query?

Another option I imagined was opening up a UI FORM where admins can actually set the test values for each field of each object and then try to run that script... is not that hard to develop... perhaps also full of caveats

afawcett commented 8 years ago

Thanks @rodriguezartav

Yes its a tricky one.... some thoughts...

Lets keep this conv going....

What kind of tool are you developing btw?

rodriguezartav commented 8 years ago

Hey @afawcett, thanks!

It's called webhooks, a tool to send record insert/updates to webhook urls so that Admin's can integrate with other services without using api calls.

http://pasteboard.co/pJ38T8g.png

I got it working with the delete trigger and allData=true , but you are right. It will fail when delete is blocked elsewhere or if there is no data.

Another thing that can be attempted is doing the same with but on update changing the field name or try some luck with a text field. Just as brittle, but when combined they might increase the changes of only using delete.

I've come to think that for this to work consistently, for an Admin to be able to write the tests without coding, a good solution would be to provide them with an UI where they can create a record and their related records - insert it. And then use all that as defaults in the auto-generated tests. The field values can be pulled from a recent existing record and have the user try inserts until all validations pass, then use the defaults to generate the test.

I'll try to make POC,

What do you think?

On Sat, Apr 23, 2016 at 6:40 PM, Andrew Fawcett notifications@github.com wrote:

Thanks @rodriguezartav https://github.com/rodriguezartav

Yes its a tricky one.... some thoughts...

  • onDelete option is not a bad thought, though if there are multiple triggers on the object, there is no gaurantee the auto generated one will fire after one that prevents delete.
  • UI Form option is something i'd also considered, as you say not sure on true mileage though
  • Record Types with default fields, i did wonder about having the user create a record type with field defaults that satisifed the insert, then using SObject.newInstance with that record type ID. That a cheaper version of the UI form idea and something they can test in the UI before passing the record type name to the tool to reference in the auto generated test. Again mileage may vary depending on what other triggers need (such as master or required lookup records).

Lets keep this conv going....

What kind of tool are you developing btw?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/afawcett/declarative-lookup-rollup-summaries/issues/332#issuecomment-213858257

Roberto Rodriguez Programador (Hacker) Costa Rica @rodriguezartav +506 8703 3825

afawcett commented 8 years ago

Ah i see, very nice! Cool UI as well! 👍

Your UI idea for sure sounds interesting, and while this is a problem to be solved, i'm not sure its that common to warrant the investment to build this type of UI tbh. This is basically how i've felt about approaching doing something about this problem before.

There has always been something else thats worth more my time on the tool. What i find is admins have an issue, get some friendly dev to write a fragment then paste that into the tools, then just keep that for future use and/or distribute that around as needed.

I also heard that Salesforce spoke at UK DUG earlier this about a generic trigger framework as part of Custom Metadata coming in the pipeline....

That said, please don't let me put you off, its just my thoughts.... :-)

rodriguezartav commented 8 years ago

Yep - I have the same feeling deep in my mind.

Actually I started setting up the env to build the app but then realized there was something else I'd better do before :)

Your are also right in that there must be enough installation problems as to require the development of the UI. I'll monitor that.

If I find that I have to do it - I'll try to make it re-usable so that if you like it - you'll be able to use it in your tool.

afawcett commented 8 years ago

@rodriguezartav i had a bit of a brain wave recently, how about giving the user the chance to write a Flow that the test could execute? The user could devleop and test the flow much more easily in clicks not code....