Aptitude (12) C (2) C++ (10) CSS (1) Data Structure (2) English (7) General (14) HTML (3) Integration (1) Itinerary and Travel Cost (1) Java (29) JQ (5) JS (5) JSP (1) Lightning (14) logical (3) Math (1) Music Notation (17) MySql (4) Network (1) Regex (1) salesforce (131) Servlet (4) SF Admin (31) SF Dev (102) SQL (4) SQL_SERVER (1) StudyPoints (2) ytChannels (2) अन्ताक्षरी (4)

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 trycatch 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: