Test Setup Methods

Hi,

Test setup methods can be time-saving when you need to create reference or prerequisite data for all test methods, or a common set of records that all test methods operate on.

We have to use "@testSetup" annotation to write test setup method.

Small Use Case for you:

Case is updating with an account when case is created with different scenarios.

Then for creating test class for the same requirement i have to create an account in each method for covering different scenarios in the logic.

But with "testsetup" method we can avoid creating the same account in multiple methods instead we can create once in testsetup method then we can utilize the same in all test methods.

Syntax:

@testSetup static void methodName() {

}

Eg:

--

@isTest

private class CommonTestSetup {

    @testSetup static void setup() {

        // Create common test accounts

        Account accountObj = new Account(Name='ABCD Account');

        insert accountObj;       

    }

   

    @isTest static void testMethod1() {

       //Create case with a scenario it can take account data from the above test method to update on case based on your original logic to cover your code

    }

    @isTest static void testMethod2() {

        //Create case with a scenario it can take account data from the above test method  to update on case based on your original logic to cover your code

    }

}

  

Note:

If a test class contains a test setup method, the testing framework executes the test setup method first, before any test method in the class. Records that are created in a test setup method are available to all test methods in the test class and are rolled back at the end of test class execution. If a test method changes those records,such as record field updates or record deletions, those changes are rolled back after

 each test method finishes execution. The next executing test method gets access to the original unmodified state of those records.

Named Credentials

Hi ,

A named credential specifies the URL of a callout endpoint and its required authentication parameters in one definition. To simplify the setup of authenticated callouts, specify a named credential as the callout endpoint. If you instead specify a URL as the callout endpoint, you must register that URL in your org’s remote site settings and handle the authentication yourself. For example, for an Apex callout, your code would need to handle authentication, which can be less secure and especially complicated for OAuth implementations.

Salesforce manages all authentication for callouts that specify a named credential as the callout endpoint so that you don’t have to. You can also skip remote site settings, which are otherwise required for callouts to external sites, for the site defined in the named credential.

Named credentials are supported in these types of callout definitions:

§  Apex callouts

§  External data sources of these types:

o   Salesforce Connect: OData 2.0

o   Salesforce Connect: OData 4.0

o   Salesforce Connect: Custom (developed with the Apex Connector Framework)

By separating the endpoint URL and authentication from the callout definition, named credentials make callouts easier to maintain. For example, if an endpoint URL changes, you update only the named credential. All callouts that reference the named credential simply continue to work.

Named credentials support basic password authentication and OAuth 2.0. You can set up each named credential to use an org-wide named principal or to use per-user authentication so that users can manage their own credentials.

To reference a named credential from a callout definition, use the named credential URL. A named credential URL contains the scheme callout:, the name of the named credential, and an optional path. For example: callout:My_Named_Credential/some_path.

You can append a query string to a named credential URL. Use a question mark (?) as the separator between the named credential URL and the query string. For example: callout:My_Named_Credential/some_path?format=json.

Example

In the following Apex code, a named credential and an appended path specify the callout’s endpoint.

HttpRequest req = new HttpRequest();
req.setEndpoint('callout:My_Named_Credential/some_path');
req.setMethod('GET');
Http http = new Http();
HTTPResponse res = http.send(req);
System.debug(res.getBody());

The referenced named credential specifies the endpoint URL and the authentication settings.

Path:Setup->Administer->Security Controls-> Named Credentials

If you use OAuth instead of password authentication, the Apex code remains the same. The authentication settings differ in the named credential, which references an authentication provider that’s defined in the org.

In contrast, let’s see what the Apex code looks like without a named credential. Notice that the code becomes more complex to handle authentication, even if we stick with basic password authentication. Coding OAuth is even more complex and is an ideal use case for named credentials.

HttpRequest req = new HttpRequest();
req.setEndpoint('https://my_endpoint.example.com/some_path');
req.setMethod('GET');

// Because we didn't set the endpoint as a named credential, 
// our code has to specify:
// - The required username and password to access the endpoint
// - The header and header information
 
String username = 'myname';
String password = 'mypwd';
  
Blob headerValue = Blob.valueOf(username + ':' + password);
String authorizationHeader = 'BASIC ' +
EncodingUtil.base64Encode(headerValue);
req.setHeader('Authorization', authorizationHeader);
   
// Create a new http object to send the request object
// A response object is generated as a result of the request  
  
Http http = new Http();
HTTPResponse res = http.send(req);
System.debug(res.getBody());
Reference:https://help.salesforce.com/articleView?id=named_credentials_about.htm&type=5
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_callouts_named_credentials.htm