Test Class Best Practices in Salesforce

This blog will explore test class best practices in Salesforce, covering everything from basic principles to advanced techniques that can enhance your testing strategy.

First and foremost, test classes in Salesforce are essential for ensuring the reliability and performance of your customizations and applications on the platform.

Moreover, writing efficient and effective test classes helps maintain code quality and ensures that your deployments and updates are smooth and error-free.

Why Test Classes Matter

Test classes are a critical component of the Salesforce development lifecycle. They ensure that your code behaves as expected and help identify and fix bugs early in the development process.

Moreover, Salesforce requires that at least 75% of your Apex code is covered by tests before you can deploy it to production, making it crucial to adhere to best practices in test writing.

What is the syntax of the Test class

Following is the basic syntax of test classes

@isTest
public class DemoClassTest {

@isTest
public static void methodLogicTest() {
}
}

Following are the best practices that we can follow while writing our test classes

1. Build the foundation of test classes

First and foremost, a test class is always marked with @istest annotation. Each test method within the class should be static and void, meaning they don’t return any values.

@isTest
public class DemoClassTest {
@isTest
static void methodLogicTest() {
// test logic
}
}

We should also use the TestSetup method to create a common set of data that can be utilised in the whole class. This approach reduces redundancy and ensures consistency across your tests. Below is the syntax for setup method

@isTest
public class DemoClassTest {

@TestSetup
static void setup() {
Account acc = new Account(Name = 'Test Account');
insert acc;
}

@isTest
public static void methodLogicTest() {
Account acc = [SELECT Id, Name FROM Account WHERE Name = 'Test Account'];
}
}

2. Create meaningful data for the test classes

We should always create meaningful data for our test classes as it helps us to unit test our application covering all the possible scenarios. We should not rely on the existing org data. Here let’s take an example

Suppose I have a contact who is inserting and then we are updating its related account active field to ‘Yes’. Let’s create it test class. There is a contact trigger which will execute after the insertion of the contact and calling our helper class DemoClass.

DemoClass.apxc

public class DemoClass {

public static void updateAccount(List<Contact>newList) {
List<Account> accListToUpdate = new List<Account>();
Set<Id>accountIds = new Set<Id>();
for(Contact con : newList) {
accountIds.add(con.AccountId);
}

for(Account acc : [SELECT Id,Description FROM Account WHERE Id IN :accountIds]) {
acc.Active__c = 'Yes';
accListToUpdate.add(acc);
}

update accListToUpdate;
}
}

DemoClassTest.apxc

@isTest
public class DemoClassTest {

@TestSetup
static void setup() {
Account acc = new Account(Name = 'Test Account', AccountNumber = '23213');
insert acc;

Contact con = new Contact();
con.AccountId = acc.Id;
con.FirstName = 'Test';
con.LastName = 'Contact';
insert con;
}

@isTest
public static void accountLogicTest() {
List<Contact> conList = [SELECT Id,AccountId,Name FROM Contact WHERE Name = 'Test Contact'];
DemoClass.updateAccount(conList);

}
}

Let’s hit the Run Test button appearing on the Test class to run our the test class. Below are the output. Here blue lines in the original class show the covered lines. So, we can see all the lines our covered and the coverage is 100%

3. Use the Test Data Factory class

Consider creating a test data factory class to generate test data. This class can centralize the creation of test records, making your test classes cleaner and easier to maintain. Below is an example of how we can create and use the test data factory class.

TestDataFactory.apxc

@isTest
public class TestDataFactory {

public static Account createAccount(String name) {
Account acc = new Account(Name = name);
insert acc;
return acc;
}

public static Contact createContact(String firstName, String lastName) {
Contact con = new Contact();
con.AccountId = createAccount('Test Account').Id;
con.FirstName = firstName;
con.LastName = lastName;
insert con;
return con;
}
}

4. Testing each conditional logic

Testing each conditional logic is good practice as it will check each scenario and also help us cover and increase code coverage. Below is a sample of updating the account active field depending on the industry.

@isTest
public class DemoClassTest {

@TestSetup
static void setup() {
Account accActive = new Account(Name = 'Test Account', AccountNumber = '23213',Industry = 'Construction');
insert accActive;

Contact conActive = new Contact();
conActive.AccountId = accActive.Id;
conActive.FirstName = 'Test';
conActive.LastName = 'Contact Active';
insert conActive;

Account accNonActive = new Account(Name = 'Test Account', AccountNumber = '23213',Industry = 'Energy');
insert accNonActive;

Contact conNonActive = new Contact();
conNonActive.AccountId = accNonActive.Id;
conNonActive.FirstName = 'Test';
conNonActive.LastName = 'Contact Non Active';
insert conNonActive;
}

@isTest
public static void accountLogicTestActive() {
List<Contact> conList = [SELECT Id,AccountId,Name FROM Contact WHERE Name = 'Test Contact Active'];
DemoClass.updateAccount(conList);
}

@isTest
public static void accountLogicTestNonActive() {
List<Contact> conList = [SELECT Id,AccountId,Name FROM Contact WHERE Name = 'Test Contact Non Active'];
DemoClass.updateAccount(conList);
}
}

5. Use Test.starTest and Test.stopTest block

Test.startTest gives us the extra set of governor limits to test our code and Test.stopTest returns to its previous governor limit. Also, we should always test our asynchronous method in this block as they behave as synchronous.

Below is the sample code for the asynchronous apex class and its test class.

QueueableDemoClass.apxc

public class QueueableDemoClass implements Queueable {

private List<Id> accountIds;

public QueueableDemoClass(List<Id> accIds) {
this.accountIds = accIds;
}

public void execute(QueueableContext context) {

List<Account> accounts = [SELECT Id, Name FROM Account WHERE Id IN :accountIds];

for (Account acc : accounts) {
acc.Name = acc.Name + ' - Updated with queueable';
}

update accounts;

//System.enqueueJob(new UpdateContactNameQueueable(accountIds));
}

}

QueueableDemoTest.apxc

@istest
public class QueueableDemoTest {

@testSetup
static void testSetupForQueueableDemoTest() {
Account acc = new Account();
acc.Name = 'Test Name';
insert acc;
}

@isTest
public static void queueableExecuteTest() {

List<Id>accountIds = new List<Id>();
Account acc = [SELECT Id FROM Account];
accountIds.add(acc.Id);

Test.startTest();
System.enqueueJob(new QueueableDemoClass(accountIds));
Test.stopTest();
}

}

6. Always aim for 90+ code coverage

While Salesforce requires 75% code coverage, aiming for 100% ensures that every line of code is tested. However, coverage alone is not enough; we must also assert that our code behaves as expected. We should cover possible scenarios to test.

7. Use proper assertions in the test class

Use the System.assert methods to verify that your code returns the expected results. Assertions are critical for validating the behaviour of your code under various conditions.

8. Always test in bulk

Ensure our code can handle bulk operations by testing with large data volumes. This practice helps identify issues related to governor limits and performance.

@isTest
public class DemoClassTest {

@TestSetup
static void setup() {
List<Account> accounts = new List<Account>();
for (Integer i = 0; i < 200; i++) {
accounts.add(new Account(Name = 'Test Account ' + i));
}
insert accounts;
}

@isTest
public static void accountLogicTest() {
Integer count = [SELECT Name FROM Account WHERE Name LIKE 'Test Account%'].size();
System.assertEquals(200, count);
}
}

9. Enforce record sharing in test class

To enforce record sharing in our test classes we should use System.runAs(u) where u is the user object which contains the specific user details. Also, it will be beneficial to avoid mixed DML errors in our test classes.

10. Test the classes in your application individually

We should never test the entire application. If we are running many tests then we should test the classes in our organization individually in the Salesforce user interface instead of using the Run All Tests button to run them all together.

Things to remember while writing test classes

1. All apex classes must have their test classes and they should cover at least 75% of your apex code.
2. All Apex triggers must have some code coverage.
3. Don’t just focus on the code coverage, make sure to cover the use cases of the application for both positive and negative.
4. If the code uses conditional logic (including ternary operators), execute each branch.
5. Complete successfully without any exceptions, unless those exceptions are expected, make sure to handle those in a try-catch block.

FAQs

1. What is @isTest(SeeAllData=true) annotation does?

By using this annotation we will be able to test with our org’s data. However, it is not a good practice to use this. We should always use @isTest(SeeAllData=false).

2. What does @TestVisible annotation do?

This annotation is used to test private methods as these are not accessible outside the class.

2. Why is it important to avoid hard-coded IDs in test classes?

Hard-coded IDs can vary between environments, making tests unreliable. Query for necessary records dynamically within your tests instead.

Conclusion

Adhering to test class best practices in Salesforce is crucial. It helps maintain code quality, ensure smooth deployments, and meet Salesforce’s code coverage requirements.

To start, you can build robust and reliable Salesforce applications by creating meaningful test data. Next, focus on coverage and assertions. Additionally, isolate tests and test bulk and edge cases. Furthermore, leverage mocking frameworks and integrate continuous testing.

Implementing these test class best practices in Salesforce will improve your development workflow. Moreover, it will also provide greater confidence in the stability and performance of your solutions.

By following these test class best practices in Salesforce, we will be well-equipped to write efficient and effective test classes. Ultimately, this will ensure the long-term success of your Salesforce projects.

Get a complete Roadmap To Learn Salesforce Admin And Development

Name *

First

Last

Email *

Comment or Message

Submit