- You must have at least 75% of your Apex covered by unit tests to deploy your code to production environments.
- All triggers must have at least one line of test coverage.
- Recommendation is always to have 100% of your code covered by unit tests, where possible.
- Calls to System.debug are not counted as part of Apex code coverage in unit tests.
- Test clases should be appended with the word Test followed by the name of the class being tested, e.g. ‘Opportunity Services Test’.
- Test classes should all use the @isTest annotation.
- Only use isTest(SeeAllData = true) on class methods in exceptional cases where there are sObjects that doesn’t allow DML operation e.g. PriceBook creation
- Test method should static and no void return type
- Testvisible annotation to make visible private methods inside test classes.
- Test method can not be used to test web-service call out. Please use mock call out
- Data in User, profile, organization, AsyncApexjob, Crontrigger, RecordType, Apex Class, Apex Component ,ApexPage objects can be accessed without (seeAllData=true) .
- Accessing static resource test records in test class e,g ListaccList=Test.loadData(Account,SobjectType,’ResourceName’)
- Create TestFactory class with @isTest annotation to exclude from organization code size limit
- @testSetup to create test records once in a method and use in every test method in the test class
- Maximum number of test classes run per 24 hour of period is not greater of 500 or 10 multiplication of test classes of your organization
- 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
- runAs will not enforce user permission or field level permission as the running user.
- No hard coded id’s of any sObject in any test method.
- Any exceptions that are caught in the production methods should be tested by feeding the test data that throws exception. Exception Type and error message should be asserted.
- Any business logic that needs to be tested should be enveloped within a Test.runAs(user) statement so profile restrictions can be tested. Using any admin profiles should be avoided.
- All private methods should also have its corresponding unit test method. In the production code, add a public method for each private method and prepend it by “exposeForUnitTest_”.
Customer experience is utmost important for Salesforce. Therefore, right from the beginning, testing and quality are continually evaluated as part of their processes. The purpose of testing in the digital environment involves many layers. It is used to check whether the code and configuration is functional, to ensure that the digital platform meets the requirement set by the client and post-testing, the software should completely support the requirement set by the client. Testing at Salesforce: Testing at Salesforce is completely done on their website and it is a rewarding experience as it brings some of the best practices, strategies and tools. The process covers both manual and automated testing. Manual software testing involves testing Salesforce.com App by using systematic approach by a professional. Automated testing involves a computer program to do the necessary check. These processes are used to test functional components of Salesforce App, load testing as well as security testing. Then there is Apex that offer a testing framework to write unit tests, run the tests, check results and also generate code coverage results. In the face of a crisis, distressing searches are made to find out if there is a clash with some inherent CSS or a class that might have been wrongly inherited. Guidelines for Code Coverage and Testing Best Practices: In order to develop a forceful and error-free code, best strategies and tools in the practice are implemented. Some of them are defined below: