Apex Trigger Best Practices :
1.One Trigger per object : The order of execution isn’t guaranteed when having multiple triggers for the same object due to the same event. For example, if you have two before insert triggers for Case, and a new Case record is inserted that fires the two triggers, the order in which these triggers fire isn’t guaranteed.
2. Trigger Should be logic less: It is best, to reduce trigger to a bare minimum and call an APEX handler class. Logic-less Triggers means that we should not write any Business logic in the Triggers. All the Business Logic should be written in separate Apex Class which is know as Trigger Handler
3.Context-specific Handler Methods : We should have different handler methods for each Trigger Context.
4.Trigger should be bulkified : Make sure the Trigger handles multiple records at a time. Always write the Trigger logic considering the fact that multiple records can be inserted, updated, or deleted at a time.
5.Use Collections and Avoid SOQL or DML in FOR loops : Always try not to include SOQL and DML in FOR loops. This is applicable not only in Triggers but also in any Apex Code. Make use of Collections like List, Set, and Maps to store the records or other details in Collection to avoid the SOQL or DML in FOR loops. Use Collections to perform DML operations rather than doing it on an individual record.
6. Use SOQL Query FOR Loop : SOQL Query can only return 50,000 records at a time. Querying Large Data Sets might exceed the heap size and hit Governor Limits. Try to optimize the Query by putting WHERE conditions in QUERY with LIMIT if applicable.
// Avoid this
list<Account> accountList = [SELECT Name, Website FROM Account WHERE Type = 'Customer'];
for(Account acc : accountList){
// Some Logic.
}
// Use THIS.
for(Account acc : [SELECT Name, Website FROM Account WHERE Type = 'Customer']){
// Some Logic.
}
APEX Code Best Practices :
1. Bulkify your Code : Making sure that Apex code can properly handles more than just one record at a time.
2. Avoid SOQL Queries or DML statements inside FOR Loops : Do not place SOQL or DML(insert/update/delete/undelete) statements inside a loop
3. Bulkify your Helper Methods : Make sure that the helper methods are properly designed to handle bulk records
4. Using Collections, Streamlining Queries, and Efficient For Loops : 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.
5. Streamlining Multiple Triggers on the Same Object : You do not have any explicit control over which trigger gets initiated first. Each trigger that is invoked does not get its own governor limits - all code that is processed, including the additional triggers, share those available resources. Instead one trigger getting a maximum of 100 queries, all triggers on that same object will share those 100 queries. So, it is critical to ensure that the multiple triggers are efficient and no redundancies exist.
6. 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. The loop can process multiple batches of records through the use of internal calls to query and query More.
7. Use of the Limits Apex Methods to Avoid Hitting Governor Limits : Use Apex Limits Methods to Avoid Hitting SF Governor Limits.
Limits.getHeapSize() Returns the amount of the resource that has been used in the current context
Limits.getLimitDmlStatements() returns the total amount of the resource that is available for that context.
8. Use @future Appropriately : Apex written within an asynchronous method gets its own independent set of higher governor limits. No more than 10 @future methods can be invoked within a single Apex transaction
9. Avoid Hardcoding IDs : Don’t hard code Id in Apex Code. When you deploying apex code between sandbox and production it may failed because id may not same. Use custom settings/ custom metadata to avoid hard coding IDs.
Apex Test class Best Practices :
1. @isTest must be used before starting the test class.
2. To define the test method, you can either use “@isTest” or “testMethod” keyword with method.
3. Always use @testSetup method dedicated to create test records for that class.
4. If possible Do not use seeAllData=true, Create your Own Test Data.
5. Use Test.startTest() and Test.StopTest() to reset Governor limits in Test methods when doing any asynchronous operation in code.
6. Use As much as Assertions like System.AssertEquals or System.AssertNotEquals.
7. We should try with positive as well as negative scenarios.
8. Use of Test.isRunningTest() method, where we cannot test a piece of code in normal manner.
9. Use of System.runAs() method -Normally, all Apex codes run in System mode, and therefore the current user’s various permissions and record sharing rules are not taken into consideration. The system method, System.runAs(),lets us write test methods that change user contexts to either an existing user or a new user.
Interview question related to test class :
Ques : Suppose, you have created a field with status = develop in test method. And in method 1 , you are updating this status field to "define". And then you want to use this status field in Method 2. what will be the value of status field ?
Ans : we will have status as "develop" only. The test methods values are not stored in database. They are temporary.
No comments:
Post a Comment