Tips and Tricks For Test Class In Salesforce

Introduction

Testing is an important part of the Salesforce development life cycle (SDLC). Therefore it is mandatory to test your code before deploying it to Production and it has a minimum of 75% code coverage i.e if your code is of 100 lines then 75 lines must be covered in test class if not then code can not be moved to production. 

Therefore, if you have a "before insertion" trigger on Contacts, just create a new Contact in the test class to get code coverage! In the beginning, it seemed that there was only enough code coverage to deploy the code. 

However, experienced developers will always take some extra steps to ensure that their code is also solid and reliable.

Some Test Scenarios You Have To Keep In Mind Before Writing a Test Class

1. Create All Records In The Test Class From Scratch:

Because the test class can not connect to the Database of your org (Unless you have specified @seeAllData = true ) so you have to create records to test them. and the second most important thing is if any record in production is deleted or changed then there is no chance that your test class failed because you have created your own records.

Don't forget to check out: How Does a Post Install Script Work? - Salesforce Developer Guide

2. Always Use System.assertEquals() To See If your Code Has The Expected Result or Not:

For Example: if your code changes an Account's stage to ‘Hot’, make sure it actually did by doing 

System.assertEquals(‘Hot’, myAccount.Stage);

3. Test For The Scenarios Where Code Gets Failed:

Suppose we have worked on a scenario when a user lost his job as a Salesforce developer did we change the stage of "Account" to "Hot". We also want to test this situation using System.assertEquals ("in relation" myAccount.Stage).

4. Test your Code for Bulk records:

Suppose you insert a single record in trigger successfully but it can be failed for 10 records (maximum 200 records can be processed in a single trigger). So, always test your code for single as well as multiple records at the same time.

5. Always use @isTest annotation instead of testMethod :

It is more flexible to use the @isTest annotation instead of the testMethod keyword because you can specify parameters in the annotation.

6. Always Use @testSetup method :

Because you have to create records only once and use them throughout the test class, if you don't use @testSetup then you have to create a fresh set of records every time for different methods.

7. Always Use Test.startTest() and Test.stopTest():

To ensure that the actual testing of the code occurs within a new set of governor limits. These methods can help you reset the governor limits before executing the actual test code.

Example: A simple test class for the trigger.

Trigger Handler Class:

public class MyFirstClass {
    public static void testMethod(Contact[] Cons) {
        for (Contact c :Cons){
            c.Price__c *= 0.9;
        }
    }
}

Apex Trigger:

trigger testClassTrigger on Contact(before insert) {
    Contact[] cons = Trigger.new;
    MyFirstClass .testMethod(cons);
}

Check out another amazing blog by Anuj here: Invoke Apex Class From JavaScript Button in Salesforce

Test Class for Trigger:

@isTest
private class MyTestClass {
    static testMethod void validateHelloWorld() {
        Contact b = new Contact(LastName='My Contact', Price__c=100);
        System.debug('Price before inserting new Contact: ' + b.Price__c); 
        Test.startTest();
        // Insert Contact
        insert b;
        Test.stopTest();
        // Retrieve the new Contact
        b = [SELECT Price__c FROM Contact WHERE Id =:b.Id];
        System.debug('Price after update: ' + b.Price__c); 
        System.assertEquals(90, b.Price__c);
    }
}

Reference: merfantz