Test Class In Salesforce

What is a Test Class in Salesforce?

A test class in Salesforce is designed to evaluate another class’s functionality—typically an Apex class, trigger, or web service. Apex test classes are used to ensure that developer-written code functions as intended before it is deployed to a production environment.

Test classes are not included in the code coverage calculation before being deployed in final production by the Salesforce administrator. Salesforce’s test classes provide around 75% code coverage, meaning that the test classes perform more than half of the testing. 

Why do we require a Test Class in Salesforce?

• Assurance of Code Quality: Test classes help ensure your Apex code is high quality and functions as expected. They provide a way to test the behaviour of your code in different scenarios and conditions.

• Regression Testing: Regression testing can be carried out using thorough test classes as your Salesforce org changes with upgrades and new features. Consequently, this ensures that any new changes won’t affect existing functionality.

• Deployment Requirements: Salesforce has deployment requirements, and one of them is achieving the minimum code coverage. Without a test class, you won’t be able to deploy your code to the production environment.

• Testing Governor Limits: Salesforce has several governor restrictions on the amount of resources used, including the quantity of DML statements and queries. Test classes let you make sure your code stays within these bounds.

• Isolation of Test Data: Test classes provide a way to isolate test data from your production data. This is crucial for maintaining data integrity and preventing unintended changes to your production data during testing.

Read More: Lightning Record Picker in Salesforce

Best Practice of Test Class in Apex

• Test class should always be initiated with @isTest annotation.
• Design your test class to handle bulk data. Additionally, test your code across a range of data volumes to make sure it functions properly in various scenarios.
• Create test data within the test class and avoid relying on existing data in the org.
• Use the @testSetup annotation for common test data shared among test methods, which reduces redundant data creation.
• Avoid hardcoding IDs whenever possible, as these can differ between environments. While unit testing, it would result in test failure due to the hard-coded ID provided.
• Using the SeeAllData=true annotation at the class or method level grants access to data. Nonetheless, if the containing class previously employed the SeeAllData=true annotation, employing SeeAllData=false on a method does not restrict organizational data access for that specific method. It’s advisable to refrain from using this annotation since while it might pass validation in a sandbox environment, it could result in failure within a production environment.
• Test your code under different user contexts using System.runAs to simulate different profiles and permissions.
• It’s recommended to use Test.startTest() and Test.stopTest(), it executes the code with the new set of governor limits.
• Each method should have one assert statement: Always include assert statements in both positive and negative test results.

Sample Test Class

Apex Class:

public class OpportunityHandler {
public static Decimal calculateOpportunityAmount(Decimal amount) {

return amount * 12;
}
}

Apex Test Class:

@isTest
private class OpportunityHandlerTest {

@isTest
static void testCalculateOppAmount() {
// Test data setup
Decimal amount = 1000;

// Test execution
Test.startTest();
Decimal amountValue = OpportunityHandler.calculateOpportunityAmount(amount);
Test.stopTest();

// Test validation
Decimal opportunityAmount = amount * 12;
System.assertEquals(opportunityAmount, amountValue, 'Amount calculation is incorrect');
}

@isTest
static void testNegativeScenario() {
// Test data setup for negative scenario
Decimal Amount = -500;

// Test execution
Test.startTest();
Decimal amountvalue = OpportunityHandler.calculateOpportunityAmount(amount);
Test.stopTest();

// Test validation
Decimal oppAmountvalue = amount * 12;
System.assertEquals(oppAmountvalue, amountvalue, 'Negative scenario not handled correctly');
}
}

Let’s consider another Test Class example where we are using the @testSetup method that creates some test data by inserting accounts with different Names and Rating values.

The testSearchForAccounts method assesses the searchForAccounts method by supplying valid search parameters and asserting the retrieval of the correct account.

In contrast, the testSearchWithNegativeScenario method specifically tests the case where no accounts should be returned.

Apex Class :

public class AccountData {
public static List<Account> searchForAccounts(String Name, String Rating) {
List<Account> accList = [SELECT Id, Name, Rating
FROM Account
WHERE Name = :Name and Rating = :rating ];
return accList;
}
}

Apex Test Class :

@isTest
public class AccountDataTest {

@testSetup
static void setupTestData() {
// Create test accounts with specific Name and Rating
List<Account> accountList = new List<Account>();
accountList.add(new Account(Name = 'TestAccount1', Rating = 'Hot'),();
accountList.add(new Account(Name = 'TestAccount2', Rating = 'Warm'));
insert accountList;
}

@isTest
static void testSearchForAccounts() {
// Test searching for accounts with valid Name and Rating
List<Account> accountResult = AccountData.searchForAccounts('TestAccount1', 'Hot');

// Assert that the correct number of accounts is returned
System.assertEquals(1, accountResult.size(), 'Expected one account to be returned');

// Assert that the returned account has the correct values
Account resultAccount = accountResult[0];
System.assertEquals('TestAccount1', resultAccount.Name, 'Unexpected Name');
System.assertEquals('Hot', resultAccount.Rating, 'Unexpected Rating');
}

@isTest
static void testSearchWithNegativeScenario() {
// Test searching for accounts with invalid Name and Rating
List<Account> accountResult = AccountData.searchForAccounts('NonExistent', 'NotRated');

// Assert that no accounts are returned
System.assertEquals(0, accountResult.size(), 'Expected no accounts to be returned');
}
}

These are basic examples, and in a real-world scenario, you would likely have more complex logic and multiple test methods to cover various scenarios. Always aim to test both positive and negative scenarios to ensure robust code coverage.

Conclusion

The blog offers a thorough rundown of Salesforce test classes, highlighting their function in guaranteeing code quality and fulfilling deployment specifications. Additionally, it emphasizes how important test classes are for isolating test data, testing governor limits, and conducting regression testing.

The article covers some of the best practices for building test classes, including using the @testSetup annotation, avoiding hardcoding IDs, and handling large data.

Overall, the blog serves as a valuable guide for Salesforce developers, offering insights into the purpose, requirements, and best practices associated with writing effective test classes in the Salesforce ecosystem.

Get a complete Roadmap To Learn Salesforce Admin And Development

Name *

First

Last

Email *

Comment or Message

Submit