How to Write a Test Class in Salesforce in 2023?

Testing is an important part of SDLC. So, before deploying our code to the production environment, Salesforce requires at least 75% of your code to be covered by our test classes, to make sure that our code doesn’t break in any situation in Production Salesforce has done this. Now, we’ll see how we write the test class with examples in Salesforce. 

How to Write a Test Class in Salesforce?

1. At least 75% of your Apex code must be covered by unit tests, and all of those tests must complete successfully. But this should not be our focus. We should aim for 100% code coverage, which ensures that you cover each positive and negative use case of your code to cover and test each and every branch of your code. 
2. System.debug is not counted as part of Apex code coverage. 
3. Test classes are not counted as part of the Apex code limit. So, we do not have to worry about writing long test classes with more methods just to make sure that all your code branches are covered. 
4. The trigger you are trying to deploy should have at least 1% coverage, but yes overall coverage of your production org after getting your code deployed should be 75%, otherwise, you won’t be able to deploy your code. 
5. The class can be deployed on 0% coverage as well, but the overall coverage of your production org after getting your code deployed should be 75%, otherwise, Salesforce won’t let you deploy your code. 

Don't forget to check out: All You Need to Know About Apex Test Class in Salesforce

In the example below, we will write a very simple test class: 

Apex Trigger

trigger HelloWorldTrigger on Book__c (before insert) 
{ 
    Book__c[] books = Trigger.new; 
    MyHelloWorld.applyDiscount(books); 
}

Trigger Helper Class

public class MyHelloWorld 
{ 
    public static void applyDiscount(Book__c[] books) 
    { 
        for (Book__c b :books)
        { 
            b.Price__c *= 0.9; 
        } 
    } 
}

Test Class Code

@isTest 
private class HelloWorldTestClass 
{ 
    static testMethod void validateHelloWorld() 
    { 
        Book__c b = new Book__c(Name='Behind the Cloud', Price__c=100); 
        System.debug('Price before inserting new book: ' + b.Price__c); 
        Test.startTest(); 
        // Insert book 
        insert b; 
        Test.stopTest(); 
        // Retrieve the new book 
        b = [SELECT Price__c FROM Book__c WHERE Id =:b.Id]; 
        System.debug('Price after trigger fired: ' + b.Price__c); 
        System.assertEquals(90, b.Price__c); 
    } 
}

Check out another amazing blog by Saurabh here: What is Queueable Apex in Salesforce?

What are the Key Points while Writing a Test Class?

1. We have to start our class with @isTest annotation, then only Salesforce will consider this class as a test class. 
2. Keep your class Private, and the best practice is to name your test class as your original Class or trigger Name + ‘Test’. 
3. Methods of test class have to be static, and void and the testMethod keyword has to be used. 
4. Preparing test data that needs to be existing before your actual test runs are multiple techniques of creating test data nowadays, for example, setup method, static resources, etc. For more details about @testsetup method check the below link @testSetup method in apex test class.
5. We should use Test.startTest() and Test.stopTest() to make sure that the actual testing of your code happens with the fresh set of governer limits. These methods help you to reset your governor limits just before your actual code of testing gets executed. 
6. Once your test code runs between Test.startTest() and Test.stopTest(), you must use assert statements to test whether your actual code is executing correctly and giving the results as expected. In our case, we are testing whether the book’s price has been set to 90 or not. If this assert statement returns false, then your test class will fail and will let you know, that something is not correct in your code, and you need to fix your original code. 
7. Because we are testing a simple trigger, we could not show the testing using negative use cases, but in an ideal world, you should write multiple methods in your test class, a few should test your positive use cases, and others should test your negative test cases.