Apex Test Class in Salesforce - Lear All About It

Introduction

• Apex testing framework enables you to write and execute tests for your apex classes and triggers on the lightning platform. 
• Apex unit tests ensure high quality for your apex code and let you meet requirements for deploying apex. 

• Apex code can only be written in a sandbox environment or a developer org, not in production. 
• apex code can be deployed to a production org from a sandbox also app developers can distribute apex code to customers from their developer org by uploading packages to the lightning platform AppExchange. 
• In addition to being critical for quality assurance apex unit test are also requirements for deploying and distributing apex. 

Benefits Of Apex Unit Test

• Ensuring that your apex classes and triggers work as expected. 
•  Having a suite of reruns every time classes and triggers are updated ensures that future updates you make to your app do not break existing functionality. 
• Meeting the code coverage requirement for deploying apex to production or distributing apex to customers via package. 
• High-quality apps delivered to the production org which make production users more effective. 

• High-quality app delivered to package subscriber which increases your customer trust. 

Don't forget to check out: All you Need to Know About Salesforce Apex Scheduler | The Ultimate Guide

Annotations

@isTest - Utilized at the Class or Method level to demonstrate it just holds back code that supports Test Coverage. Classes characterized with this comment don't mean something negative for your association limit for Apex code. 

@testSetup - used to demonstrate a strategy is explicitly used to set up test information. When provided, the @testSetup strategy is executed before some other techniques in the test class. Each test strategy will approach the first arrangement of built test information paying little mind to how some other test technique utilizes that information. 

@testVisible - When building Apex rationale, it's a good idea to characterize individuals like strategies, factors, and inward classes as private or secured. Doing such, in any case, can make accomplishing Test Coverage really testing. Luckily, Salesforce has thought ahead and given us the @testVisible comment. Utilizing this explanation on private or safeguarded individuals permits test class access yet saves the characterized perceivability to non-test classes. 

@isTest(SeeAllData=True) - Ideally, your Salesforce test classes ought to be answerable for making their own information. Nonetheless, once in a while you want admittance to existing information, and utilizing @isTest(SeeAllData=True) permits your test classes and test strategies this entrance. Accessible as of API adaptation 24.0, there are a few provisos while utilizing. "SeeAllData=True" can be utilized at the Class and Method level. While utilizing "SeeAllData=True" at the Class level, all strategies gain admittance to existing information yet utilizing "SeeAllData=True" at simply the Method level just permits those Methods admittance to existing information. In conclusion, utilizing "SeeAllData=False" at the Method level won't abrogate "SeeAllData=True" utilized at the Class level. 

@isTest(isParallel=true) — Use the @isTest(isParallel=true) explanation to demonstrate test classes that can run in equal. Default limits on the number of simultaneous tests don't have any significant bearing on these test classes. 

Code Coverage Requirement for Deployment

• Before you can deploy your code or package it for the lightning platform AppExchange at least 75% of the apex code must be covered by the test and all those tests must pass. 
• In addition, each trigger must have some coverage even though code coverage is a requirement for deployment do not write tests only to meet this requirement 

•  Make sure to test the common use cases in your app including positive and negative test cases and bulk and single record processing. 

Check out an amazing Salesforce video tutorial here: Salesforce Apex Tutorial for beginners | Apex Salesforce Tutorial

Remember

• Calls to system.debug are not considered pieces of summit code inclusion. 
•  Test strategies and test classes are not considered pieces of the summit code limit. so no stresses over writting long test class with additional strategies just to ensure that are your branches are coverd. 

• Cass can be sent on o% inclusion also yet that general inclusion of your creation organization in the wake of getting your code conveyed ought to be 75% in any case Salesforce won't allow you to send your code.) 

Syntax

Test method:

@isTest 
static void testname(){ 
    //Code block....... 
} 
or 
static testMethod void testname(){ 
    // Code Block..... 
}

Test Class with Test Method

@isTest 
private class MyTestclass{ 
    @isTest 
    static void myTestMethod(){ 
        //Code Block...... 
    } 
}