Code Coverage Best Practices

Code Coverage General Tips

  1. Run tests to refresh code coverage numbers. Code coverage numbers aren't refreshed when updates are made to Apex code in the organization unless tests are rerun.
  2. If the organization has been updated since the last test run, the code coverage estimate can be incorrect. Rerun Apex tests to get a correct estimate.
  3. The overall code coverage percentage in your organization doesn’t include code coverage from managed package tests. The only exception is when managed package tests cause your triggers to fire. For more information, seeManaged Package Tests.
  4. Coverage is based on the total number of code lines in the organization. Adding or deleting lines of code changes the coverage percentage. For example, let's say an organization has 50 lines of code covered by test methods. If you add a trigger that has 50 lines of code not covered by tests, the code coverage percentage drops from 100% to 50%. The trigger increases the total code lines in the organization from 50 to 100, of which only 50 are covered by tests.

Why Code Coverage Numbers Differ between Sandbox and Production

When Apex is deployed to production or uploaded as part of a package to the Force.com AppExchange, Salesforce runs local tests in the destination organization. Sandbox and production environments often don’t contain the same data and metadata, so the code coverage results don’t always match. If code coverage is less than 75% in production, increase the coverage to be able to deploy or upload your code.
The following are common causes for the discrepancies in code coverage numbers between your development or sandbox environment and production. This information can help you troubleshoot and reconcile those differences.
1.Test Failures
If the test results in one environment are different, the overall code coverage percentage doesn’t match. Before comparing code coverage numbers between sandbox and production, make sure that all tests for the code that you’re deploying or packaging pass in your organization first. The tests that contribute to the code coverage calculation must all pass before deployment or a package upload.
2.Data Dependencies
If your tests access organization data by using the @isTest(SeeAllData=true) annotation, the test results can differ depending on which data is available in the organization. If the records referenced in a test don’t exist or have changed, the test fails or different code paths are executed in the Apex methods. Modify tests so that they create test data instead of accessing organization data.
3.Metadata Dependencies
Changes in the metadata, such as changes in the user’s profile settings, can cause tests to fail or execute different code paths. Make sure that the metadata in sandbox and production match, or ensure that the metadata changes aren’t the cause of different test execution behavior.
4.Managed Package Tests
Code coverage that is computed after you run all Apex tests in the user interface, such as the Developer Console, can differ from code coverage obtained in a deployment. If you run all tests, including managed package tests, in the user interface, the overall code coverage in your organization doesn’t include coverage for managed package code. Although managed package tests cover lines of code in managed packages, this coverage is not part of the organization’s code coverage calculation as total lines and covered lines. In contrast, the code coverage computed in a deployment after running all tests through the RunAllTestsInOrg test level includes coverage of managed package code. If you are running managed package tests in a deployment through the RunAllTestsInOrg test level, we recommend that you run this deployment in a sandbox first or perform a validation deployment to verify code coverage.
5.Deployment Resulting in Overall Coverage Lower Than 75%
When deploying new components that have 100% coverage to production, the deployment fails if the average coverage between the new and existing code doesn’t meet the 75% threshold. If a test run in the destination organization returns a coverage result of less than 75%, modify the existing test methods or write additional test methods to raise the code coverage over 75%. Deploy the modified or new test methods separately or with your new code that has 100% coverage.
6.Code Coverage in Production Dropping Below 75%
Sometimes the overall coverage in production drops below 75%, even though it was at least 75% when the components were deployed from sandbox. Test methods that have dependencies on the organization’s data and metadata can cause a drop in code coverage. If the data and metadata have changed sufficiently to alter the result of dependent test methods, some methods can fail or behave differently. In that case, certain lines are no longer covered.

Recommended Process for Matching Code Coverage Numbers for Production

  1. Use a Full Sandbox as the staging sandbox environment for production deployments. A Full Sandbox mimics the metadata and data in production and helps reduce differences in code coverage numbers between the two environments.
  2. To reduce dependecies on data in sandbox and production organizations, use test data in your Apex tests.
  3. If a deployment to production fails due to insufficient code coverage, write more tests to raise the overall code coverage to the highest possible coverage or 100%. Retry the deployment.
  4. If a deployment to production fails even after you raise code coverage numbers in sandbox, run local tests from your production organization. Identify the classes with less than 75% coverage. Write additional tests for these classes in sandbox to raise the code coverage.
No comments:

Testing Best Practices || Test Classess Best Practice


  1. Cover as many lines of code as possible.
    1. At least 75% of your Apex code must be covered by unit tests, and all of those tests must complete successfully
    2. When deploying Apex to a production organization, each unit test in your organization namespace is executed by default.
    3. Calls to System.debug are not counted as part of Apex code coverage
    4. Test methods and test classes are not counted as part of Apex code coverage.
    5. While only 75% of your Apex code must be covered by tests, your focus shouldn't be on the percentage of code that is covered. Instead, you should make sure that every use case of your application is covered, including positive and negative cases, as well as bulk and single records. This should lead to 75% or more of your code being covered by unit tests.
    6. Every trigger must have some test coverage.atleast 1% coverage.
    7. All classes and triggers must compile successfully.
  2. If code uses conditional logic (including ternary operators), execute each branch.
  3. Make calls to methods using both valid and invalid inputs.
  4. Complete successfully without throwing any exceptions, unless those errors are expected and caught in a try…catch block.
  5. Always handle all exceptions that are caught, instead of merely catching the exceptions.
  6. Use System.assert methods to prove that code behaves properly.
  7. Use the runAs method to test your application in different user contexts.
  8. Exercise bulk trigger functionality—use at least 20 records in your tests.
  9. Use the ORDER BY keywords to ensure that the records are returned in the expected order.
  10. 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.
  11. Set up test data:
    1. Create the necessary data in test classes, so the tests do not have to rely on data in a particular organization.
    2. Create all test data before calling the Test.startTest method.
    3. Since tests don't commit, you won't need to delete any data.
  12. 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.
  13. Test the classes in your application individually. Never test your entire application in a single test.
  14. If you are running many tests, consider the following:
    1. In the Force.com IDE, you may need to increase the Read timeout value for your Apex project. Seehttps://developer.salesforce.com/page/Apex_Toolkit_for_Eclipse for details.
    2. In the Salesforce user interface, you may need to test the classes in your organization individually, instead of trying to run all the tests at the same time using the Run All Tests button.

Best Practices for Parallel Test Execution*

Tests that are started from the Salesforce user interface (including the Developer Console) run in parallel. Parallel test execution can speed up test run time. Sometimes, parallel test execution results in data contention issues, and you can turn off parallel execution in those cases. In particular, data contention issues and UNABLE_TO_LOCK_ROW errors might occur in the following cases:
  • When tests update the same records at the same time. Updating the same records typically occurs when tests don’t create their own data and turn off data isolation to access the organization’s data.
  • When a deadlock occurs in tests that are running in parallel and that try to create records with duplicate index field values. A deadlock occurs when two running tests are waiting for each other to roll back data, which happens if two tests insert records with the same unique index field values in different orders.
You can prevent receiving those errors by turning off parallel test execution in the Salesforce user interface:
  1. From Setup, enter Apex Test.
  2. Click Options....
  3. In the Apex Test Execution Options dialog, select Disable Parallel Apex Testing and then click OK.
Apex Test Execution Options

 
No comments:
Subscribe to: Posts (Atom)

Counters