Scenario: Production org has sufficient code coverage with unit-tests. Someone adds validation rule(s) which cause the tests to break. Minimum 75% code coverage is no longer there. We come along to add new code (were not involved in the orginal code). When we go to deploy our code which itself has sufficient coverage the deployment fails due to the newly added validation rules breaking the tests on the legacy code.
Options here are
- Review all the legacy code written by a third party and update it and its tests so it handles the newly added validation rules - not really viable in some cases, neither the client nor ourselves want that expense.
- Manually disable the validation rules which are breaking the legacy code unit-tests for the duration of the deployment - not ideal, but the route I've been forced to take on occasion.
- ???
Attribution to: David Gillen
Possible Suggestion/Solution #1
I have seen a solution that uses a Custom Setting of ValidationRuleEnabled.
ALL validation rules set up have the && $Setup.CustomSetting__c.ValidationRuleEnabled__c added.
When you want to deploy any code then the administrator changes the Custom Setting to FALSE, deploy the new code; don't forget to re-enable the Custom Setting!
Again this is not ideal as the 'legacy' code should be updated to accommodate the new validation rules; ideally at the time of creating the new validation rules (but who checks code coverage after making a small change like a validation rule?)
Attribution to: Jason Lawrence
Possible Suggestion/Solution #2
The use of $Setup.CustomSetting_c.ValidationRuleEnabled_c is very creative.
I typically handle this by making sure that any records I create using "UNITTEST" in the Name field and then check for NAME != "UNITTEST" in the validation rule.
The issue with legacy code still exists. Ideally, Salesforce.com will come up with a simple function for ISUNITTEST().
Attribution to: Force2b_Mike
Possible Suggestion/Solution #3
I vote for #1 - update all existing code written by other people, etc. Why? It's very clean and makes sure that the code still works with those validations in place or not. What happens if you have a validation rule that requires a field if X,Y,Z and your Apex code had not previously assumed this to be true. In fact what if your Apex code assumed that the field would be blank if X,Y,Z? If you bypass the validation rule the Apex code would still pass it's tests, but in production when the field was filled in when X,Y,Z the Apex code would break.
Edge case to be sure and for the most part we all agree that it's painful when new validation rules break your or past tests so I'd bet most people do #2 (disable it) and then when they have time go back and do #1 (clean test code).
One thing that can really really help is if you create a 'TestDataGenerator' class that is responsible for creating all of your test data, then you only need to modify the code there as opposed to everywhere. Of course this doesn't help for your unmanaged packages installed off the AppExchange, but at least helps you with your code.
If you really want to bypass the validation rules what I typically do is check the user's profile. Typically you can set it up so System Admin or a custom profile "Apex Admin" doesn't have to have the validation apply. Much like the CustomSetting, however if you use the custom setting during the deployment no user has the validation apply whereas with a check to profile only the user(s) with that profile can bypass the validation.
Looking forward to hearing more folk's thoughts on this one!
Attribution to: caleb
Possible Suggestion/Solution #4
I've seen a couple approaches that have all worked well in certain scenarios.
1) Smarter Validation Rules - For non critical validation rules give tests a hook to disable them (test user's profile, custom setting, etc.)
2) Build a Utility Class for Data Creation - Class is responsible for returning an object that can be saved and nothing more. All tests use this as a starting point. If a new validation rule breaks your test you only have to update one place.
3) Turn off the Validation Rules for Deployment - Not ideal, but it works. Can be scripted pretty easily (download all validation rules to eclipse, save to source control, find and replace to inactivate them, save, deploy, revert)
If you're stuck with a ton of legacy code option 3 is the only one that seems viable to me. But for new code, make sure whoever builds your code follows #2. And if you're considering building code, take into account that you'll need a developer to maintain it.
Finally, look into setting up an automated test running framework. At least then you'll know right away when you're tests break as opposed to the day a big deployment is supposed to go live.
Attribution to: Ralph Callaway
Possible Suggestion/Solution #5
I've done a simple 3 steps Validation Rule ON/OFF switch - using the Tooling API. We use that while loading data from Prod -> Partial. Maybe it's also useful for someone here .. repo link below.
GitHub: Validation Rule ON/OFF Switch
Attribution to: Heiko
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/63