I need to create an Org. Wide Email address for my Test Class, and I can't seem to find documentation for this. One forum led me to believe it wasn't possible, but it wasn't clear if I was understanding it correctly. Advice?
2 Answers
You can't set up an OrgWideEmailAddress
. Attempting to do so gives this error:
DML operation Insert not allowed on OrgWideEmailAddress
Fortunately, you can see them perfectly fine without SeeAllData=true
. I even took the time to verify it with a simple unit test:
// This class is in version 43.0, SeeAllData=false by default
@isTest class q224877 {
@isTest static void test() {
OrgWideEmailAddress[] addresses = [SELECT Id FROM OrgWideEmailAddress LIMIT 1];
System.assertEquals(1, addresses.size());
}
}
This test, of course, passes. Typically speaking, when you're not sure if something applies to your scenario, write a unit test. Doing so saves you the trouble of trying to figure out something like this and waiting for an answer. This test took me about a minute to type up.
-
Hi, thank you for your answer - I knew SeeAllData would work, I've just been pressed time after time after time NOT to do that, so I was hoping the answer was in creating it with code; since that's best practice, I figured there was a way to create it that I missed and was just wondering what it was - I guess there isn't one. Sorry about that Jul 12, 2018 at 19:26
-
@NataliePaige Do not use SeeAllData. There's no need, since it's a type of metadata that doesn't need this feature.– sfdcfoxJul 12, 2018 at 19:27
-
@NataliePaige The best practice is to use the most appropriate method for the task at hand. For all "standard" objects, create your own data. For most "metadata" types, you can query them directly without creating them or using SeeAllData=true.– sfdcfoxJul 12, 2018 at 19:28
-
1The problem, of course, is that you're now dependent on whatever org-wide e-mail addresses happen to be on the org you're testing on. So first of all: you don't have the ability to set up different sets of data and test your method under each of them to see that it produces the desired outcome. And your test may very well do different things depending on the org on which it is run. Specifically, your test would fail on a newly created scratch org.– FransFeb 10 at 12:25
-
@Frans Yes, there are some kinds of untestable code, unfortunately. However, I think in most cases, you could use dependency injection to at least get the required coverage. I agree it'd be ideal to be able to create those in Apex. I'd suggest posting this on the Idea Exchange.– sfdcfoxFeb 10 at 14:40
To add on to @sfdcfox's answer it may be a good idea to setup a unit test to email a specifc Organziation-wide-Address to confirm 1.) it does exist 2.) It has been verified by the given email address. Maybe something like this?:
OrgWideEmailAddress specificOrgWideEmailAddress = [SELECT Id, Address FROM OrgWideEmailAddress WHERE DisplayName = 'Display Name of Specific Org Wide address'];
EmailTemplate emailTemplate = [SELECT Id FROM EmailTemplate WHERE DeveloperName = 'Test_Template'];
List<Messaging.SingleEmailMessage> emailMessagesToSend = new List<Messaging.SingleEmailMessage>();
Contact testContact = TestUtility.buildTestContact(<testcontactinfo>);
insert testContact;
Id contactId = testContact.Id;
Messaging.SingleEmailMessage email = new Messaging.SingleEmailMessage();
email.setOrgWideEmailAddressId(specificOrgWideEmailAddress.Id);
email.setTemplateID(emailTemplate.Id);
email.setTargetObjectId(contactId);
emailMessagesToSend.add(email);
Test.startTest();
List<Messaging.SendEmailResult> results = Messaging.sendEmail(emailMessagesToSend ,false);
Test.stopTest();
Boolean emailsSentSuccessfully = results[0].isSuccess();
System.assert(emailsSentSuccessfully , 'Email failure occurred. Confirm the Organization-Wide-Address is setup and VERIFIED for Specific Org Wide address given');
OrgWideEmailAddress
is not mentioned specifically, sure seems like setup data.