Best Practice for Test classes | Sample Test class

In this post we will talk about best practice for test classes with test class examples in Salesforce. We will also talk about how to write Salesforce test class for controller, test class for Standard Controller, test class for trigger in salesforce with example.

What to Test In Apex?

Salesforce.com recommends the following components need to test.

1. Single Records: 

This includes testing to verify that a single record produces the correct, expected result

2. Bulk Records: 

Any apex code, whether a triggers, a class or on extension may be used for 1to 200 records we must test not only the single record case, but the bulk cases as well.

3. Positive scenarios: 

This type of component testing expect a system to save a record without error.

4. Negative scenarios: 

This type of component testing expect a system to give error.

5. Restricted User: 

Test whether a user with restricted access to the objects used in code sees the expected behavior, i.e whether they can run the code or receive error messages.

Here Example of Test Classes

Test Class for Trigger

@isTest 
public class TriggerTestClass 
{
    static testMethod void testMethod1() 
 {
  // Perform DML here only
 
        }
}

Test Class for Standard Controller

@isTest 
public class ExtensionTestClass 
{
 static testMethod void testMethod1() 
 {
 Account testAccount = new Account();
 testAccount.Name='Test Account record' ;
 insert testAccount;

 Test.StartTest(); 
  ApexPages.StandardController sc = new ApexPages.StandardController(testAccount);
  myControllerExtension testAccPlan = new myControllerExtension(sc);

  PageReference pageRef = Page.AccountPlan; // Add your VF page Name here
  pageRef.getParameters().put('id', String.valueOf(testAccount.Id));
  Test.setCurrentPage(pageRef);

  //testAccPlan.save(); call all your function here
 Test.StopTest();
 }
}

Test Class for Controller class

@isTest 
public class ControllerTestClass 
{
 static testMethod void testMethod1() 
 {
 Account testAccount = new Account();
 testAccount.Name='Test Account record' ;
 insert testAccount;

 Test.StartTest(); 

  PageReference pageRef = Page.AccountPlan; // Add your VF page Name here
  pageRef.getParameters().put('id', String.valueOf(testAccount.Id));
  Test.setCurrentPage(pageRef);

  myController testAccPlan = new myController();
  
  //testAccPlan.save(); call all your function here
 Test.StopTest();
 }
}

Test Class for StandardSetController

@isTest 
public class TestStandardSetController 
{
 static testMethod void testMethod1() 
 {
 List <Account> lstAccount = new List<Account>();
 
 Account testAccount = new Account();
 testAccount.Name='Test Account' ;
 lstAccount.add(testAccount);
 Account testAccount1 = new Account();
 testAccount1.Name='Test Account11' ;
 lstAccount.add(testAccount1);

 insert  lstAccount;
 
 Test.startTest();
  Test.setCurrentPage(Page.YOUR_PAGE);
  ApexPages.StandardSetController stdSetController = new ApexPages.StandardSetController(lstAccount);
  stdSetController.setSelected(lstAccount);
  YOUR_Extension ext = new YOUR_Extension(stdSetController);
 Test.stopTest();
 }
}

Please follow below salesforce Best Practice for Test Classes :-

1. Test class must start with @isTest annotation if class class version is more than 25
2. Test environment support @testVisible, @testSetup as well
3. Unit test is to test particular piece of code working properly or not .
4. Unit test method takes no argument, send no email , commit no data to database and flagged with testMethod keyword .
5. To deploy to production at least 75% code coverage is required
6. Test method and test classes are not counted as a part of code limit7. System.debug statement are not counted as a part of apex code limit.8. We should not focus on the  percentage of code coverage ,we should make sure that every use case should covered including positive, negative,bulk and single record .

• Single Action -To verify that the the single record produces the correct an expected result .
• Bulk action -Any apex record trigger ,class or extension must be invoked for 1-200 records .
• Positive behavior : Test every expected behavior occurs through every expected permutation , i,e user filled out every correctly data and not go past the limit .
• Negative Testcase :-Not to add future date , Not to specify negative amount.
• Restricted User :-Test whether a user with restricted access used in your code .

9. Test class should be annotated with @isTest .
10 . @isTest annotation with test method  is equivalent to testMethod keyword .
11. Test method should static and no void return type .
12. Test class and method default access is private ,no matter to add access specifier .
13. Classes with @isTest annotation can't be a interface or enum .
14. Test method code can't be invoked by non test request .
15. Stating with salesforce API 28.0 test method can not reside inside non test classes .
16. @Testvisible annotation to make visible private methods inside test classes.
17. Test method can't be used to test web-service call out . Please use call out mock .
18. You can't  send email from test method.
19.User, profile, organization, AsyncApexjob, Corntrigger, RecordType, ApexClass, ApexComponent ,ApexPage we can access without (seeAllData=true) .
20. SeeAllData=true will not work for API 23 version eailer .
21. Accessing static resource test records in test class e,g List<Account> accList=Test.loadData(Account,SobjectType,'ResourceName').
22. Create TestFactory class with @isTest annotation to exclude from organization code size limit .
23. @testSetup to create test records once in a method  and use in every test method in the test class .
24. We can run unit test by using Salesforce Standard UI,Force.com IDE ,Console ,API.
25. As apex runs in system mode so the permission and record sharing are not taken into account . So we need to use system.runAs to enforce record sharing .
26. System.runAs will not enforce user permission or field level permission .
27. Every test to runAs count against the total number of DML issued in the process .

Please check below post to learn more about test classes.

1) Code Coverage Report in excel Format | Test Class Result in XLS

2) Salesforce Testing Best Practice Guidelines | Unit Test Mechanism in Salesforce   

3) StartTest and stopTest Method

4) Test classes with @isTest

5) @testSetup ( Set Up Test Data for an Entire Test Class )

6) How to write test class for Scheduler /Schedulable class in Salesforce

7) Test Utility Classes | TestDataFactory | Util Test in salesforce

 

 

Please let us know if this post will help you


Thanks
Amit Chaudhary

Salesforce Testing Best Practice Guidelines | Unit Test Mechanism in Salesforce | Test Methods

Unit Test Mechanism in Salesforce

1) Single action

Test to verify that a single record produces the correct, expected result. So created the unit test data in your test class.

2) Bulk actions

Any Apex code, whether a trigger, a class or an extension, may be invoked for 1 to 200 records. You must test not only the single record case, but the bulk cases as well.

3) Restricted user

Test whether a user with restricted access to the sObjects used in your code sees the expected behavior. That is, whether they can run the code or receive error messages. Always use RunAs for to check user access on sObjects.

4) Positive behaviour

Test to verify that the expected behaviour occurs through every expected permutation, that is, that the user filled out everything correctly and did not go past the limits.

5) Negative behaviour

There are likely limits to your applications, such as not being able to add a future date, not being able to specify a negative amount, and so on. You must test for the negative case and verify that the error messages are correctly produced as well as for the positive, within the limits cases.

Test Methods

1) Apply testMethod or @isTest to methods

      • Demarcates a single self-contained test

public class MyClass 
{
  @isTest  
    private static void myTest() 
   {
      // code block
   }
}

2) Apply @isTest to classes

• Optional: test methods may also be contained in public classes
• Won’t count against the 2MB/org Apex code limit
– @isTest methods will not be shown in code coverage results
• The class must be marked as private
• Public methods can’t be called from outside the class

@isTest 
private class MyTestClass 
{
   @isTest private static void myTest() 
   {
 // code block
   }
}

Apex tests will not:

1.  Commit changes to the database.
2.  But SOQL queries will find records created during the test.
3.  Perform callouts to external Web services.
4.  Send outbound email.
5.  Return results from SOSL searches.

Test Requirements in Production

1. 75% of Apex statements must be executed (strive for 100% code coverage)
2. All Apex triggers must be called. 
3. All Apex tests must execute without throwing any uncaught exceptions or exceeding governors.

Step 1: Positive Path

Verify that when passed valid inputs, called code completes without throwing an exception.

Step 2: End state

• Verify data-defined outcomes with assertions
• System.assert()
• System.assertEquals()
• System.assertNotEquals()

Step 3: Negative Path

Verify that when passed invalid inputs, exceptions are properly handled

Step 4: Governors

• Verify that code is bulk ready.
• Pass up to 200 records.
• Trade-off between test performance and effectiveness

Please let us know if this post will help you.


Thanks,
Amit Chaudhary

Trigger Best Practices | Sample Trigger Example | Implementing Trigger Framework

1) One Trigger Per Object

A single Apex Trigger is all you need for one particular object. If you develop multiple Triggers for a single object, you have no way of controlling the order of execution if those Triggers can run in the same contexts

2) Logic-less Triggers

If you write methods in your Triggers, those can’t be exposed for test purposes. You also can’t expose logic to be re-used anywhere else in your org.

3) Context-Specific Handler Methods

Create context-specific handler methods in Trigger handlers

4) Bulkify your Code

Bulkifying Apex code refers to the concept of making sure the code properly handles more than one record at a time.

5) Avoid SOQL Queries or DML statements inside FOR Loops

An individual Apex request gets a maximum of 100 SOQL queries before exceeding that governor limit. So if this trigger is invoked by a batch of more than 100 Account records, the governor limit will throw a runtime exception

6) Using Collections, Streamlining Queries, and Efficient For Loops

It is important to use Apex Collections to efficiently query data and store the data in memory. A combination of using collections and streamlining SOQL queries can substantially help writing efficient Apex code and avoid governor limits

7) Querying Large Data Sets

The total number of records that can be returned by SOQL queries in a request is 50,000. If returning a large set of queries causes you to exceed your heap limit, then a SOQL query for loop must be used instead. It can process multiple batches of records through the use of internal calls to query and queryMore

8) Use @future Appropriately

It is critical to write your Apex code to efficiently handle bulk or many records at a time. This is also true for asynchronous Apex methods (those annotated with the @future keyword). The differences between synchronous and asynchronous Apex can be found

9) Avoid Hardcoding IDs

When deploying Apex code between sandbox and production environments, or installing Force.com AppExchange packages, it is essential to avoid hardcoding IDs in the Apex code. By doing so, if the record IDs change between environments, the logic can dynamically identify the proper data to operate against and not fail

Always remember below points before writing trigger :-
1) Order Of Execution
2) Recursive Trigger
3) Learn about Other Trigger Framework with Recording

Here is sample code for Trigger Handler framework Code :-

Create one Trigger "AccountTrigger"

trigger AccountTrigger on Account( after insert, after update, before insert, before update)
{

    AccountTriggerHandler handler = new AccountTriggerHandler(Trigger.isExecuting, Trigger.size);
    
    if( Trigger.isInsert )
    {
        if(Trigger.isBefore)
        {
            handler.OnBeforeInsert(trigger.New);
        }
        else
        {
            handler.OnAfterInsert(trigger.New);
        }
    }
    else if ( Trigger.isUpdate )
    {
        if(Trigger.isBefore)
        {
            handler.OnBeforeUpdate(trigger.New ,trigger.Old,Trigger.NewMap,Trigger.OldMap);
        }
        else
        {
            handler.OnAfterUpdate(trigger.New ,trigger.Old,Trigger.NewMap,Trigger.OldMap);
        }
    }
}

Create one Trigger Handler Class

public with sharing class AccountTriggerHandler 
{
    private boolean m_isExecuting = false;
    private integer BatchSize = 0;
    public static boolean IsFromBachJob ;
    public static boolean isFromUploadAPI=false;
    
    public AccountTriggerHandler(boolean isExecuting, integer size)
    {
        m_isExecuting = isExecuting;
        BatchSize = size;
    }
            

    public void OnBeforeInsert(List<Account> newAccount)
    {
        system.debug('Account Trigger On Before Insert');
    }
    public void OnAfterInsert(List<Account> newAccount)
    {
        system.debug('Account Trigger On After Insert');
    }
    public void OnAfterUpdate( List<Account> newAccount, List<Account> oldAccount, Map<ID, Account> newAccountMap , Map<ID, Account> oldAccountMap )
    {
        system.debug('Account Trigger On After Update ');
        AccountActions.updateContact (newAccount);
    }
    public void OnBeforeUpdate( List<Account> newAccount, List<Account> oldAccount, Map<ID, Account> newAccountMap , Map<ID, Account> oldAccountMap )
    {
        system.debug('Account Trigger On Before Update ');
    }

    @future 
    public static void OnAfterUpdateAsync(Set<ID> newAccountIDs)
    {

    }      
    public boolean IsTriggerContext
    {
        get{ return m_isExecuting;}
    }
    
    public boolean IsVisualforcePageContext
    {
        get{ return !IsTriggerContext;}
    }
    
    public boolean IsWebServiceContext
    {
        get{ return !IsTriggerContext;}
    }
    
    public boolean IsExecuteAnonymousContext
    {
        get{ return !IsTriggerContext;}
    }
} 

Create one Trigger Action Class

public without sharing class AccountActions 
{
    public static void updateContact ( List<Account> newAccount)
    {
        // Add your logic here
    }
}

Source of link :-

https://developer.salesforce.com/page/Trigger_Frameworks_and_Apex_Trigger_Best_Practices
https://developer.salesforce.com/page/Apex_Code_Best_Practices
http://amitsalesforce.blogspot.in/2015/03/how-to-stop-recursive-trigger-in.html
http://amitsalesforce.blogspot.in/2015/01/triggers-and-order-of-execution.html


Thanks,
Amit Chaudhary