Today I’m going to talk about two of my go-to “tools” (for lack of a better term) when it comes to testing functionality in any Salesforce org that I do work in. I don’t always do these things…(but when I do….*never mind*) though I’m starting to do them more often and its been working for me.

The first of these items also comes up often in the #salesforce IRC channel as well and its been talked about in many places but I see this brought up so often that its probably a good idea to mention it yet again.

Use Hierarchy Custom Settings to “short circuit Validation Rules, Workflow Rules and even Triggers. (If you aren’t sure what Custom Settings are or what they do, then watch this video[1]). These are very valuable not only for day to day operations, but also in my unit tests. The idea for unit testing is to test small chunks of functionality. Sometimes things like Validation Rules can get in the way of that. If you’re testing a bit of code that operates on an opportunity, but that functionality doesn’t care whether or not certain fields are required, use the Custom Setting to turn off the Validation Rules that would fire so you don’t have to populate a bunch of fields that you aren’t testing/don’t care about.

For example lets say we have some validation rules in place that ensure a specific group of fields are filled out on an opportunity. Further more, lets say that we are testing a trigger that will create some child object(s) when that opportunity is created/updated, etc. If all we really want to test is whether or not that trigger works when an opportunity is inserted, why run validation on that opportunity? (Unless of course those child objects depend on these fields, lets assume they don’t for now). If our Validation Rules have the short circuit in place, our test code can turn them off in our test to ensure we don’t get errors. This is also valuable because IF we are breaking our tests down into small bite-sized chunks, when someone comes along later and adds a Validation Rule it won’t break our test. (Again, this will assume those creating the Validation Rule are inspecting our Custom Setting first, so it will take some cooperation). So lets say we have a Custom Setting called Admin Settings and a checkbox on that custom setting called Run Validation Rules. In our test setup, or in the test itself we can simply do this:

Admin_Settings__c settings = Admin_Settings__c.getInstance();
settings.Run_Validation_Rules__c = false;
insert settings;

Now when our test code runs the Validation Rule will be skipped. If we get in the habit of doing this for all of our Validation Rules, Workflow Rules, etc. then we can keep things pretty clean and not so brittle. Its never a nice surprise when you go to deploy a changeset and tests start failing because someone added a Validation Rule in production! Of course there are times when you are testing larger chunks of code or functionality and you’ll want to ensure that these rules run. In that case, instead of setting Run Validation Rules to false, just set it to true and you should be good to go.

You can also use this short circuit in triggers by creating another checkbox field on Admin  Settings called Run Triggers and in your trigger inspect that field to see if its true or false:

Admin_Settings__c settings = Admin_Settings__c.getInstance();
if(settings.Run_Triggers__c == true) {
    doIt();
}

You could even get really specific and create custom settings for different objects. Maybe don’t want to short circuit all VRs or WFRs. You could get more specific with fields like: “Run Opportunity Validation Rules” etc…

The second tidbit isn’t necessarily Salesforce specific as you can use this all over the place. I was actually surprised by the number of people that didn’t know you could do this so that’s why its here.

Take advantage of Gmails flexible email addresses.  For instance, if my email is thedude@ihatetheeagles.com, I have several ways that emails can be addressed to me:

• thedude@ihatetheeagles.com
• the.dude@ihatetheeagles.com
• the.d.ud.e@ihatetheeagles.com (etc)
• thedude+test1@ihatetheeagles.com
• thedude+myappname@ihatetheeagles.com (etc)

You get the idea. I’m not sure if other email services allow this and if so great, use them. I use them to have unique email addresses on my test users/contacts etc but still have all messages come to my email address when testing. You could potentially use this as a form of getting a stream of messages on a per-app basis and applying a filter in gmail to automatically archive/apply label to messages coming in to thedude+myapp1@ihatetheeagles.com to have groups of messages filtered out by app. If I’m doing a ton of testing and messages that are coming to me are coming from different areas of the app, I can use these addresses even to figure out what app, what part of an app, etc the messages are coming from.

What are some of your favorite goto nuggets for testing, or anything for that matter? As always if there is something you perhaps want me to deep dive on, let me know in the comments.

P.S. I actually love the Eagles…

 

[1] video found on youtube, author: Shannon Hale (@shannonsans)

:wq!