Best Practices for writing Test Class in Salesforce

• You must have at least 75% of your Apex covered by unit tests to deploy your code to production environments. In addition, all triggers must have some (at least 1%) test coverage.
• We recommend that you 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.
• Use Test.loadData () method to load test data from Static resources.
• Use Test.starttest() and Test.starttest() to reset governor limits.
• Use test setup methods (methods that are annotated with @testSetup) to create test records once and then access them in any test method in the test class.
• In the case of conditional logic (including ternary operators), execute each branch of code logic.
• Make calls to methods using both valid and invalid inputs.
• Complete successfully without throwing any exceptions, unless those errors are expected and caught in a try…catch block.
• Use Limits Class to avoid governor limits related issues.
• Always handle all exceptions that are caught, instead of merely catching the exceptions.
• Use System.assert methods to prove that code behaves properly.
• Use the runAs method to test your application in different user contexts.
• Use the isTest annotation. Classes defined with the isTest annotation do not count against your organization limit of 2 MB for all Apex code. See IsTest Annotation.
• Exercise bulk trigger functionality—use at least 20 records in your tests.
• Use the ORDER BY keywords to ensure that the records are returned in the expected order.
• Not assume that record IDs are in sequential order.
• Record IDs are not created in ascending order unless you insert multiple records with the same request. For example, if you create an account A, and receive the ID 001D000000IEEmT, then create account B, the ID of account B may or may not be sequentially higher.
• On the list of Apex classes, there is a Code Coverage column. If you click the coverage percent number, a page displays, highlighting all the lines of code for that class or trigger that are covered by tests in blue, as well as highlighting all the lines of code that are not covered by tests in red. It also lists how many times a particular line in the class or trigger was executed by the test
• Write comments stating not only what is supposed to be tested, but the assumptions the tester made about the data, the expected outcome, and so on.
• Test the classes in your application individually. Never test your entire application in a single test.
• Set up test data:

·         Create the necessary data in test classes, so the tests do not have to rely on data in a particular organization.

·         Create all test data before calling the Test.starttest () method.

·         Since tests don't commit, you won't need to delete any data.

• If you are running many tests, consider the following:

·         In the Force.com IDE, you may need to increase the Read timeout value for your Apex project. See https://wiki.developerforce.com/index.php/Apex_Toolkit_for_Eclipse for details.

·         In the Salesforce user interface, you may need to test the classes in your organization individually, instead of trying to run all of the tests at the same time using the Run All Tests button.

·         Create Test Suites of Commonly Used Apex Test Classes Available only from Spring 16.

·         Check the disable parallel apex testing when your performing  Run All test