Use System.Assert on Declarative Features

Clash 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

asked 1 hour ago

Brooks Johnson

867

add a comment | 

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

asked 1 hour ago

Brooks Johnson

867

add a comment | 

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

asked 1 hour ago

Brooks Johnson

867

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

asked 1 hour ago

Brooks Johnson

867

share|improve this question

asked 1 hour ago

Brooks Johnson

867

share|improve this question

share|improve this question

asked 1 hour ago

Brooks Johnson

867

asked 1 hour ago

Brooks Johnson

867

asked 1 hour ago

Brooks Johnson

867

867

add a comment | 

add a comment | 

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

answered 29 mins ago

Jayant Das

6,5571320

add a comment | 

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

answered 17 mins ago

sfdcfox

228k10176390

add a comment | 

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

answered 7 mins ago

David Reed

20.4k31640

add a comment | 

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

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

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

Name Email

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

answered 29 mins ago

Jayant Das

6,5571320

add a comment | 

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

answered 29 mins ago

Jayant Das

6,5571320

add a comment | 

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

answered 29 mins ago

Jayant Das

6,5571320

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

answered 29 mins ago

Jayant Das

6,5571320

share|improve this answer

share|improve this answer

answered 29 mins ago

Jayant Das

6,5571320

answered 29 mins ago

Jayant Das

6,5571320

answered 29 mins ago

Jayant Das

6,5571320

6,5571320

add a comment | 

add a comment | 

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

answered 17 mins ago

sfdcfox

228k10176390

add a comment | 

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

answered 17 mins ago

sfdcfox

228k10176390

add a comment | 

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

answered 17 mins ago

sfdcfox

228k10176390

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

answered 17 mins ago

sfdcfox

228k10176390

share|improve this answer

share|improve this answer

answered 17 mins ago

sfdcfox

228k10176390

answered 17 mins ago

sfdcfox

228k10176390

answered 17 mins ago

sfdcfox

228k10176390

228k10176390

add a comment | 

add a comment | 

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

answered 7 mins ago

David Reed

20.4k31640

add a comment | 

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

answered 7 mins ago

David Reed

20.4k31640

add a comment | 

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

answered 7 mins ago

David Reed

20.4k31640

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

answered 7 mins ago

David Reed

20.4k31640

share

share

answered 7 mins ago

David Reed

20.4k31640

answered 7 mins ago

David Reed

20.4k31640

answered 7 mins ago

David Reed

20.4k31640

20.4k31640

add a comment | 

add a comment | 

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

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

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email