3

Scenario: I have built a solution for a Customer and I have used Apex for this solution.The deployment went well. But after few months the customer added some validation rules to the Sobject and when they ran the test classes in the Org, My test classes broke.

Question: 1. How can i build my test classes dynamically so that it does not break in the customer's destination Org(if the customer adds more validation rules or makes some field mandatory after deployment of code)?
2. How do installed packages overcome problems like this?

  • 2
    It is not as easy as you would think. There is also an app exchange package that will provide the framework for you to accomplish this where org config and validation rules will not break your test methods and allows you complete control over your test data as well. As for installed packages, they do not overcome it and they do not have to. most test in managed packages fail in the customers orgs – Eric Jun 16 '16 at 4:14
  • @EricThanks for your comment, I wonder if test classes fail for installed packages doesn't it impact code coverage of the installed package's code and bring down the destination Org overall code coverage? – Kiran Jun 16 '16 at 17:15
  • Managed package code has no effect on customer org code coverage. – Eric Jun 16 '16 at 17:48
  • @Eric So installed packages can deploy code without the requirement of 75% code coverage , basically mandatory code coverage rule does not apply for installed package ? – Kiran Jun 16 '16 at 21:55
  • 1
    Packages must meet 75% is the dev org when they are packaged. Since the test typically fail in the customers org the requirements for the package to meet 75% are not enforced and the code coverage of the managed class have no effect on the customers overall code coverage. I am not 100% sure but I believe that if a customers org is < 75% you can still install managed packages but have not tried it. Bottom line is when it comes to the customers code the managed package is irrelevant when it comes to code coverage – Eric Jun 17 '16 at 0:57
3

1.For required fields, you can use the describe information to find out which fields are required, and attempt to fill them in. For other validation rules (such as one required custom date field that must be in the past, and another required custom date field that must be in the future), you pretty much can't do it. There's an idea at success.salesforce.com to vote up to add the ability to turn off validations in tests.

2.Installed packages do not always overcome this problem. I've seen plenty of tests fail in the package after it's been installed. Since I can't see the code, I can't guarantee that validation was the problem, but in some cases it was pretty clear.

| improve this answer | |
  • It can be done. Its a lot of work though. If the org has the budget there is an app on the appexchage that will allow you to do (easily) what you state you cannot. – Eric Jun 16 '16 at 4:16
  • 1
    @jochen Thanks for your answer, i wonder if test classes fail for installed packages does't it impact code coverage of the installed package's code and bring down the destination Org overall code coverage? – Kiran Jun 16 '16 at 12:38
1

This is one of the reasons code requires maintenance, and where possible, point and click should be used instead of code.

For example, if I create an "application" or coded solution for your org and you later install a trigger that's essentially a "validation trigger". I'm not aware of any way that can be detected programmatically. It's not a validation rule, but it has the effect of making fields required that may not have previously been required.

I can't anticipate those kinds of things when I created my coded solution. Dynamic Apex won't find them for me. They may or may not turn up using the metadata API, depending of course on how the code was written in the trigger. However, I can't easily call that API from Apex can I?

Will my client want to pay me to "future proof" my code? In my experience, most are reluctant to spend money for "better or best" practices test classes that include more than just obtaining line coverage with a single record. So, will they want to pay for these features? That could be a very tough sell. Sadly, code is too often purchased solely on price, at least until something breaks...

| improve this answer | |
  • 1
    Thanks for your response, but is there way to access regular validations rules and build test classes based out of them? – Kiran Jun 16 '16 at 12:43
  • Not other than through the metadata. There are a couple of managed packages that I believe can now do this. Smart Factory is an unmanged package avail from Github, but I believe you have to create you own class to handle the validation rules that need to be included. Check it out to get the details as I've not stayed current. Also look in the app exchange as the ones that can do this aren't exactly inexpensive. – crmprogdev Jun 16 '16 at 13:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.