Test Class

Testing Best Practices

Good tests should do the following:

• Cover as many lines of code as possible. Before you can deploy Apex or package it for the Force.com AppExchange, the following must be true.
  Important

  

  • At least 75% of your Apex code must be covered by unit tests, and all of those tests must complete successfully.
    Note the following.

    • When deploying to a production organization, every unit test in your organization namespace is executed.
    • Calls to System.debug are not counted as part of Apex code coverage.
    • Test methods and test classes are not counted as part of Apex code coverage.
    • 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.
  • Every trigger must have some test coverage.
  • All classes and triggers must compile successfully.
• 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.
• 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.
• 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 ID001D000000IEEmT, 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 the lines of code for that class or trigger that are covered by tests in blue, as well as highlighting 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.
• 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 starttest method.
  • Since tests don't commit, you won't need to delete any data.
• 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.

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. Seehttps://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 Testsbutton.