All You Need to Know About Apex Test Class in Salesforce

• You may create and run tests for your apex classes and triggers on the lightning platform using the apex testing framework. 
• Apex unit tests help you meet requirements for delivering Apex and guarantee the excellent quality of your Apex code. 
• Only in a developer org or a sandbox environment, not in a live environment, can Apex code be created. 
• Apex code can be uploaded as a package to the Lightning Platform App Exchange, where it can then be distributed to customers from a development org. Apex code can also be deployed from a sandbox to a production org. 
• Apex unit tests are necessary for deploying and dispersing apex in addition to being essential for quality assurance. 

 Benefits Of Apex Unit Test 

• Ensuring that your triggers and apex classes perform as planned. 
• To make sure that future upgrades you make to your app do not damage existing functionality, have a suite of repeat each time classes and triggers are altered. 
• Apex must satisfy the code coverage criteria before being put into production or given to customers as a package. 
• High-quality apps that are provided to the production org increase the productivity of the production user  
• Delivering high-quality apps to package subscribers builds their faith in you. 

Don't forget to check out: Invoke Apex Class From JavaScript Button in Salesforce

Annotations 

1. @isTest - At the class or method level, @isTest is used to show that it only holds back code that helps with test coverage. Classes marked with this comment have no negative implications for the number of associations you can have with the Apex code. 
2. @testSetup - is expressly used to build up test data when a technique is being demonstrated. The @testSetup strategy is done before various other test class strategies when it is present. Each test strategy will approach the first organization of developed test data without considering how another test methodology would use that data. 
3.  @testVisible - Characterizing persons like tactics, components, and internal classes as private or secured is a wonderful notion while developing Apex justification. In any case, carrying out Test Coverage might become extremely challenging. Fortunately, Salesforce foresaw our need and provided the @testVisible comment. When applied to private or protected individuals, this explanation allows test class access while preserving the characterized permeability for non-test classes. 
4.  @isTest(SeeAllData=True) - In a perfect world, your Salesforce test classes would be responsible for creating their own data. But occasionally you need access to current data, and using @isTest(SeeAllData=True) gives your test classes and test strategies this access. There are a few restrictions while using it as of API version 24.0. You can use "SeeAllData=True" at the Class and Method levels. All strategies can access existing data when "SeeAllData=True" is used at the Class level, but only those methods can access existing data when "SeeAllData=True" is used at the Method level. Using "SeeAllData=False" at the Method level will not override "SeeAllData=True" at the Class level, to sum up. 
5. @isTest(isParallel=true) - Use the @isTest(isParallel=true) explanation to show that test classes are capable of running in parallel. These test classes are unaffected by the standard caps on the number of concurrent tests. 

Code Coverage Requirement for Deployment  

• At least 75% of the apex code needs to be covered by tests, and all of those tests need to pass before you can deploy your code or bundle it for the lightning platform AppExchange.  
• Although code coverage is a prerequisite for deployment, each trigger must also have some coverage. Do not build tests simply to satisfy this criterion. 
• Make sure to test your app's frequent use scenarios, such as bulk and single record processing, positive and negative test cases, and so on. 

Read another amazing blog by Ashutosh here: Get Started with Salesforce Scratch Org | The Developer Guide

Remember  

• Calls to the system. Debug is not considered a piece of summit code inclusion. 
• Test strategies and test classes are not considered pieces of the summit code limit. So, no stresses over writing long test classes with additional strategies just to ensure that your branches are covered. 
• 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...... 
     }
}