Use System.Assert on Declarative Features

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
3
down vote

favorite












I hope this is not a foolish question but would there be any value to writing test classes for Flows and Process Builder? Not to check code coverage but to use assertions. I am starting to get better on the programmatic side of things and wondering if a Test Class that uses system.assertequals on Processes and Flows would help to ensure that they are doing what they are supposed to?






unit-test process-builder visual-workflow







share|improve this question



























    up vote
    3
    down vote

    favorite












    I hope this is not a foolish question but would there be any value to writing test classes for Flows and Process Builder? Not to check code coverage but to use assertions. I am starting to get better on the programmatic side of things and wondering if a Test Class that uses system.assertequals on Processes and Flows would help to ensure that they are doing what they are supposed to?






    unit-test process-builder visual-workflow







    share|improve this question























      up vote
      3
      down vote

      favorite









      up vote
      3
      down vote

      favorite











      I hope this is not a foolish question but would there be any value to writing test classes for Flows and Process Builder? Not to check code coverage but to use assertions. I am starting to get better on the programmatic side of things and wondering if a Test Class that uses system.assertequals on Processes and Flows would help to ensure that they are doing what they are supposed to?






      unit-test process-builder visual-workflow







      share|improve this question













      I hope this is not a foolish question but would there be any value to writing test classes for Flows and Process Builder? Not to check code coverage but to use assertions. I am starting to get better on the programmatic side of things and wondering if a Test Class that uses system.assertequals on Processes and Flows would help to ensure that they are doing what they are supposed to?






      unit-test process-builder visual-workflow




      unit-test process-builder visual-workflow






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 1 hour ago









      Brooks Johnson

      867




      867




















          3 Answers
          3






          active

          oldest

          votes

















          up vote
          2
          down vote













          Here's my take.



          You write "Test Classes" to Unit Test your custom "Apex Class" which in turn performs some business logic, updates some records, etc written in your "Apex Class". You use System.assert to perform assertions on the outcomes after what your code would have operated on a record. And that most importantly you also need a "Test Class" because your custom code needs coverage before deployment to Production.



          Now, Process Builder is just a point-and-click tool to automate your Business Process in another way. But it ultimately performs on a record. So if you want to use System.assert, that would mean that you are still performing assertions on the outcomes of the process builder.



          While you would have ideally performed unit tests, qa/uat tests which would have confirmed your Process Builder outcomes, but if at all you want to extend this by writing Test Classes, I would think you can still do that. Say you have a Process Builder where after you insert a record on object A, it updates XYZ field on a record of object B. So that way you can create two records in your test class and thus perform those assertions.



          So in general, you can still write test classes not specifically on the "type of tool" you are using, but instead to test what and how your records perform and that if that meets the expected scenario.






          share|improve this answer



























            up vote
            0
            down vote













            The ability to write tests for flows are relatively limited, simply because the flow engine can't be easily manipulated from Apex. While one might argue that there is some benefit to such a test, without a way to properly inspect the state of the flow like we can with @TestVisible, I suspect that most flows wouldn't be easily testable without exposing variables unnecessarily, which would clutter the UI when you're using flows in processes, etc. If you wanted to spend the time doing this, I would say it wouldn't hurt anything, I'm just not convinced you'd get any benefit out of it.



            For Process Builder, though, you could indeed write tests to make sure the logic works. This also helps prevents things like forgetting to deploy the process, activating the process, making sure your business logic is enforced, etc. I wouldn't spend a lot of time on such tests, but I can definitely see the value in doing so. I do know that sometimes Process Builder behaves oddly in unit tests, though, so this might also cause false positives as well.






            share|improve this answer



























              up vote
              0
              down vote













              The value of unit tests for declarative automations (PB, Flow, and Workflow Rules) is probably highest if you use continuous integration pervasively, not just for your Apex code. Even though the behavior of those declarative automations is usually pretty easy to document through simple UI interactions, they can interact in interesting ways with your code, each other, and simple declarative customizations like validation rules and lookup field filters.



              If you introduce a new validation rule, for example, and run all your unit tests, you'll immediately know which Apex classes or tests are impacted by the change. If you've written unit tests for your declarative automation too, you can catch problems there before you have to go all the way to UAT, which can cut the length of the testing cycle way down.





              share




















                Your Answer







                StackExchange.ready(function()
                var channelOptions =
                tags: "".split(" "),
                id: "459"
                ;
                initTagRenderer("".split(" "), "".split(" "), channelOptions);

                StackExchange.using("externalEditor", function()
                // Have to fire editor after snippets, if snippets enabled
                if (StackExchange.settings.snippets.snippetsEnabled)
                StackExchange.using("snippets", function()
                createEditor();
                );

                else
                createEditor();

                );

                function createEditor()
                StackExchange.prepareEditor(
                heartbeatType: 'answer',
                convertImagesToLinks: false,
                noModals: false,
                showLowRepImageUploadWarning: true,
                reputationToPostImages: null,
                bindNavPrevention: true,
                postfix: "",
                onDemand: true,
                discardSelector: ".discard-answer"
                ,immediatelyShowMarkdownHelp:true
                );



                );













                 

                draft saved


                draft discarded


















                StackExchange.ready(
                function ()
                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f233396%2fuse-system-assert-on-declarative-features%23new-answer', 'question_page');

                );

                Post as a guest

















                3 Answers
                3






                active

                oldest

                votes








                3 Answers
                3






                active

                oldest

                votes









                active

                oldest

                votes






                active

                oldest

                votes








                up vote
                2
                down vote













                Here's my take.



                You write "Test Classes" to Unit Test your custom "Apex Class" which in turn performs some business logic, updates some records, etc written in your "Apex Class". You use System.assert to perform assertions on the outcomes after what your code would have operated on a record. And that most importantly you also need a "Test Class" because your custom code needs coverage before deployment to Production.



                Now, Process Builder is just a point-and-click tool to automate your Business Process in another way. But it ultimately performs on a record. So if you want to use System.assert, that would mean that you are still performing assertions on the outcomes of the process builder.



                While you would have ideally performed unit tests, qa/uat tests which would have confirmed your Process Builder outcomes, but if at all you want to extend this by writing Test Classes, I would think you can still do that. Say you have a Process Builder where after you insert a record on object A, it updates XYZ field on a record of object B. So that way you can create two records in your test class and thus perform those assertions.



                So in general, you can still write test classes not specifically on the "type of tool" you are using, but instead to test what and how your records perform and that if that meets the expected scenario.






                share|improve this answer
























                  up vote
                  2
                  down vote













                  Here's my take.



                  You write "Test Classes" to Unit Test your custom "Apex Class" which in turn performs some business logic, updates some records, etc written in your "Apex Class". You use System.assert to perform assertions on the outcomes after what your code would have operated on a record. And that most importantly you also need a "Test Class" because your custom code needs coverage before deployment to Production.



                  Now, Process Builder is just a point-and-click tool to automate your Business Process in another way. But it ultimately performs on a record. So if you want to use System.assert, that would mean that you are still performing assertions on the outcomes of the process builder.



                  While you would have ideally performed unit tests, qa/uat tests which would have confirmed your Process Builder outcomes, but if at all you want to extend this by writing Test Classes, I would think you can still do that. Say you have a Process Builder where after you insert a record on object A, it updates XYZ field on a record of object B. So that way you can create two records in your test class and thus perform those assertions.



                  So in general, you can still write test classes not specifically on the "type of tool" you are using, but instead to test what and how your records perform and that if that meets the expected scenario.






                  share|improve this answer






















                    up vote
                    2
                    down vote










                    up vote
                    2
                    down vote









                    Here's my take.



                    You write "Test Classes" to Unit Test your custom "Apex Class" which in turn performs some business logic, updates some records, etc written in your "Apex Class". You use System.assert to perform assertions on the outcomes after what your code would have operated on a record. And that most importantly you also need a "Test Class" because your custom code needs coverage before deployment to Production.



                    Now, Process Builder is just a point-and-click tool to automate your Business Process in another way. But it ultimately performs on a record. So if you want to use System.assert, that would mean that you are still performing assertions on the outcomes of the process builder.



                    While you would have ideally performed unit tests, qa/uat tests which would have confirmed your Process Builder outcomes, but if at all you want to extend this by writing Test Classes, I would think you can still do that. Say you have a Process Builder where after you insert a record on object A, it updates XYZ field on a record of object B. So that way you can create two records in your test class and thus perform those assertions.



                    So in general, you can still write test classes not specifically on the "type of tool" you are using, but instead to test what and how your records perform and that if that meets the expected scenario.






                    share|improve this answer












                    Here's my take.



                    You write "Test Classes" to Unit Test your custom "Apex Class" which in turn performs some business logic, updates some records, etc written in your "Apex Class". You use System.assert to perform assertions on the outcomes after what your code would have operated on a record. And that most importantly you also need a "Test Class" because your custom code needs coverage before deployment to Production.



                    Now, Process Builder is just a point-and-click tool to automate your Business Process in another way. But it ultimately performs on a record. So if you want to use System.assert, that would mean that you are still performing assertions on the outcomes of the process builder.



                    While you would have ideally performed unit tests, qa/uat tests which would have confirmed your Process Builder outcomes, but if at all you want to extend this by writing Test Classes, I would think you can still do that. Say you have a Process Builder where after you insert a record on object A, it updates XYZ field on a record of object B. So that way you can create two records in your test class and thus perform those assertions.



                    So in general, you can still write test classes not specifically on the "type of tool" you are using, but instead to test what and how your records perform and that if that meets the expected scenario.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered 29 mins ago









                    Jayant Das

                    6,5571320




                    6,5571320






















                        up vote
                        0
                        down vote













                        The ability to write tests for flows are relatively limited, simply because the flow engine can't be easily manipulated from Apex. While one might argue that there is some benefit to such a test, without a way to properly inspect the state of the flow like we can with @TestVisible, I suspect that most flows wouldn't be easily testable without exposing variables unnecessarily, which would clutter the UI when you're using flows in processes, etc. If you wanted to spend the time doing this, I would say it wouldn't hurt anything, I'm just not convinced you'd get any benefit out of it.



                        For Process Builder, though, you could indeed write tests to make sure the logic works. This also helps prevents things like forgetting to deploy the process, activating the process, making sure your business logic is enforced, etc. I wouldn't spend a lot of time on such tests, but I can definitely see the value in doing so. I do know that sometimes Process Builder behaves oddly in unit tests, though, so this might also cause false positives as well.






                        share|improve this answer
























                          up vote
                          0
                          down vote













                          The ability to write tests for flows are relatively limited, simply because the flow engine can't be easily manipulated from Apex. While one might argue that there is some benefit to such a test, without a way to properly inspect the state of the flow like we can with @TestVisible, I suspect that most flows wouldn't be easily testable without exposing variables unnecessarily, which would clutter the UI when you're using flows in processes, etc. If you wanted to spend the time doing this, I would say it wouldn't hurt anything, I'm just not convinced you'd get any benefit out of it.



                          For Process Builder, though, you could indeed write tests to make sure the logic works. This also helps prevents things like forgetting to deploy the process, activating the process, making sure your business logic is enforced, etc. I wouldn't spend a lot of time on such tests, but I can definitely see the value in doing so. I do know that sometimes Process Builder behaves oddly in unit tests, though, so this might also cause false positives as well.






                          share|improve this answer






















                            up vote
                            0
                            down vote










                            up vote
                            0
                            down vote









                            The ability to write tests for flows are relatively limited, simply because the flow engine can't be easily manipulated from Apex. While one might argue that there is some benefit to such a test, without a way to properly inspect the state of the flow like we can with @TestVisible, I suspect that most flows wouldn't be easily testable without exposing variables unnecessarily, which would clutter the UI when you're using flows in processes, etc. If you wanted to spend the time doing this, I would say it wouldn't hurt anything, I'm just not convinced you'd get any benefit out of it.



                            For Process Builder, though, you could indeed write tests to make sure the logic works. This also helps prevents things like forgetting to deploy the process, activating the process, making sure your business logic is enforced, etc. I wouldn't spend a lot of time on such tests, but I can definitely see the value in doing so. I do know that sometimes Process Builder behaves oddly in unit tests, though, so this might also cause false positives as well.






                            share|improve this answer












                            The ability to write tests for flows are relatively limited, simply because the flow engine can't be easily manipulated from Apex. While one might argue that there is some benefit to such a test, without a way to properly inspect the state of the flow like we can with @TestVisible, I suspect that most flows wouldn't be easily testable without exposing variables unnecessarily, which would clutter the UI when you're using flows in processes, etc. If you wanted to spend the time doing this, I would say it wouldn't hurt anything, I'm just not convinced you'd get any benefit out of it.



                            For Process Builder, though, you could indeed write tests to make sure the logic works. This also helps prevents things like forgetting to deploy the process, activating the process, making sure your business logic is enforced, etc. I wouldn't spend a lot of time on such tests, but I can definitely see the value in doing so. I do know that sometimes Process Builder behaves oddly in unit tests, though, so this might also cause false positives as well.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered 17 mins ago









                            sfdcfox

                            228k10176390




                            228k10176390




















                                up vote
                                0
                                down vote













                                The value of unit tests for declarative automations (PB, Flow, and Workflow Rules) is probably highest if you use continuous integration pervasively, not just for your Apex code. Even though the behavior of those declarative automations is usually pretty easy to document through simple UI interactions, they can interact in interesting ways with your code, each other, and simple declarative customizations like validation rules and lookup field filters.



                                If you introduce a new validation rule, for example, and run all your unit tests, you'll immediately know which Apex classes or tests are impacted by the change. If you've written unit tests for your declarative automation too, you can catch problems there before you have to go all the way to UAT, which can cut the length of the testing cycle way down.





                                share
























                                  up vote
                                  0
                                  down vote













                                  The value of unit tests for declarative automations (PB, Flow, and Workflow Rules) is probably highest if you use continuous integration pervasively, not just for your Apex code. Even though the behavior of those declarative automations is usually pretty easy to document through simple UI interactions, they can interact in interesting ways with your code, each other, and simple declarative customizations like validation rules and lookup field filters.



                                  If you introduce a new validation rule, for example, and run all your unit tests, you'll immediately know which Apex classes or tests are impacted by the change. If you've written unit tests for your declarative automation too, you can catch problems there before you have to go all the way to UAT, which can cut the length of the testing cycle way down.





                                  share






















                                    up vote
                                    0
                                    down vote










                                    up vote
                                    0
                                    down vote









                                    The value of unit tests for declarative automations (PB, Flow, and Workflow Rules) is probably highest if you use continuous integration pervasively, not just for your Apex code. Even though the behavior of those declarative automations is usually pretty easy to document through simple UI interactions, they can interact in interesting ways with your code, each other, and simple declarative customizations like validation rules and lookup field filters.



                                    If you introduce a new validation rule, for example, and run all your unit tests, you'll immediately know which Apex classes or tests are impacted by the change. If you've written unit tests for your declarative automation too, you can catch problems there before you have to go all the way to UAT, which can cut the length of the testing cycle way down.





                                    share












                                    The value of unit tests for declarative automations (PB, Flow, and Workflow Rules) is probably highest if you use continuous integration pervasively, not just for your Apex code. Even though the behavior of those declarative automations is usually pretty easy to document through simple UI interactions, they can interact in interesting ways with your code, each other, and simple declarative customizations like validation rules and lookup field filters.



                                    If you introduce a new validation rule, for example, and run all your unit tests, you'll immediately know which Apex classes or tests are impacted by the change. If you've written unit tests for your declarative automation too, you can catch problems there before you have to go all the way to UAT, which can cut the length of the testing cycle way down.






                                    share











                                    share


                                    share










                                    answered 7 mins ago









                                    David Reed

                                    20.4k31640




                                    20.4k31640



























                                         

                                        draft saved


                                        draft discarded















































                                         


                                        draft saved


                                        draft discarded














                                        StackExchange.ready(
                                        function ()
                                        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f233396%2fuse-system-assert-on-declarative-features%23new-answer', 'question_page');

                                        );

                                        Post as a guest
































































                                        Comments

                                        Post a Comment

                                        Popular posts from this blog

                                        What does second last employer means? [closed]

                                        Image
                                        Clash Royale CLAN TAG #URR8PPP .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0; up vote -3 down vote favorite Say, for example I have worked in the following companies, Company A => 2010 - 2011 Company B => 2011 - 2012 Company C => 2012 - Till Date Company D => Have offer Now assume Company D is asking to submit documents from my second last employer. So from the list of companies given, which company would be qualified as second last employer? software-industry employer share | improve this question asked Aug 10 '14 at 5:16 Rajaprabhu Aravindasamy 559 1 6 13 closed as off-topic by Jim G., jmort253 ♦ Aug 11 '14 at 1:58 This question appears to be off-topic. The users who voted to close gave this specific reason: "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address...
                                        Read more

                                        Installing NextGIS Connect into QGIS 3?

                                        Image
                                        Clash Royale CLAN TAG #URR8PPP .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0; up vote 1 down vote favorite Just acquired free version of NEXTGIS and trying to install the plugin for QGIS. It tells me it was not designed for version 3 of QGIS. How do I set up the QGIS-NEXTGIS interface then? qgis qgis-plugins nextgis share | improve this question edited 3 hours ago PolyGeo ♦ 51.9k 17 77 233 asked 4 hours ago IanGS 16 4 New contributor IanGS is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. add a comment  |  up vote 1 down vote favorite Just acquired free version of NEXTGIS and trying to install the plugin for QGIS. It tells me it was not designed for version 3 of QGIS. How do I set up the QGIS-NEXTGIS interface then? qgis qgis-plugin...
                                        Read more

                                        List of Gilmore Girls characters

                                        Image
                                        The season three cast—(Back row): Lane, Michel, Paris, Emily, Richard, Sookie, Miss Patty, Kirk; Front row: Jess, Luke, Lorelai, Rory, Dean This is a list of characters for the comedy-drama television series Gilmore Girls . Contents 1 Main characters 1.1 Lorelai Gilmore 1.2 Rory Gilmore 1.3 Sookie St. James 1.4 Lane Kim 1.5 Michel Gerard 1.6 Luke Danes 1.7 Emily Gilmore 1.8 Richard Gilmore 1.9 Paris Geller 1.10 Dean Forester 1.11 Jess Mariano 1.12 Kirk Gleason 1.13 Jason Stiles 1.14 Logan Huntzberger 2 Major recurring characters 2.1 Christopher Hayden 2.2 Jackson Belleville 2.3 Mrs. Kim 2.4 Tristin DuGray 2.5 Max Medina 2.6 Taylor Doose 2.7 Dave Rygalski 2.8 Marty 3 Recurring characters 3.1 Stars Hollow 3.2 Chilton 3.3 Yale 3.4 Other 4 Notable guest stars 5 Unseen characters 6 Notes 7 References Main characters Actor Character Appearances Season 1 Season 2 Season 3 Season 4 Season 5 Season 6 Season 7 A Year in the Life Lauren Graham Lorelai Gilmore...
                                        Read more