+ Start a Discussion

Should I disable workflow rules while testing apex?

I provide a standardized but unmanaged package to clients who have different workflow needs. The workflows sometimes interfere when I deploy new code. Does it make sense to just turn them off, deploy, and turn them on again? That would mean that after deployment when I turn them back on again, the tests would fail.  Doesn't seem optimal.


Example: Some of my clients use validation rules that accept only certain amounts for membership dues. They all have different amounts. On top of it they sometimes change the amounts. When I test code for the online payments module, I insert opportunities with random amounts, but if those amounts aren't the same as the ones the client instance accepts, the test fails. I could modify the test amounts to fit the current validation rule, but later the organization could change the accepted amounts and the test would fail again.


I suppose I could put the client membership dues amounts in a custom setting so I could set them via in the test, but then I couldn't use them in workflow rules unless they were heirarchies (which they aren't).


Any easy solutions to this?


Thanks, Baird


If you agree that we should be able to turn off specific workflows and validation rules in apex tests, vote for this idea: https://success.salesforce.com/ideaView?id=08730000000BrpCAAS


Bhawani SharmaBhawani Sharma

Your question sounds very reasonable and I am totally agree as you are creating a separate package, test methods will be get failed if client has some specific rule implemented on his side. Rule can be different for different clients.
As such, there is not feature in Salesforce to turnoff rules from Apex. What the best would be here is,

you can use, Test.loadData method. In that case, you can upload a test data file on client's static resources and use that. So if there are any org specific validation rules, you can update your data file and put it back in static resource.


Additionally, when you are creating data in test method, you can catch DML exception. In case of no exception, test methods will be passed, but if exception occurs, you can cover as much as possible in catch block.


Bhawani Sharma,


That sounds like a reasonable path, and one I hadn't thought of.  I'll try it.  Thanks for your suggestion.