Force.com IDE Developer Guide
jTest Code with the Force.com IDE
One of the most important and powerful features of the Lightning platform is its built-in support for automated testing. The Apex language includes the ability to define and execute unit tests, which are pieces of code that verify that your application works the way you intended. Each unit test is defined as a test method, and you can execute your test methods to see which tests are passing or failing. Regularly executing test methods gives you instant insight into the quality of your code and provides an early warning system for detecting regressions.
There are two common ways to measure your code’s quality using unit tests.
- Code coverage identifies which lines of code a set of unit tests exercises. Code coverage is reported as a percentage. This metric helps you identify the sections of code that are untested and therefore at greatest risk of containing a bug or introducing a regression. Each time you run a set of unit tests on the Lightning platform, a code coverage number is returned. A list of uncovered lines of code in the classes and triggers invoked by the tests is also returned.
- Test case coverage identifies real-world scenarios in which you expect your code to execute. Even if you have 100% code coverage, bugs can be hiding in your code. To help prevent bugs, ensure that your test values reflect the full set of real-world possibilities, including corner cases. Test cases are not actual unit tests, but are documents that specify what your unit tests are intended to do. High test case coverage means that most or all of the real-world scenarios that you have identified are implemented as unit tests.
Developing a rich set of automatic tests gives you confidence that your code works correctly. Having good test coverage can help you catch bugs when a code change suddenly causes a test to fail. Having a robust set of tests helps us help you, too. Salesforce executes all your tests before each major release to help us avoid regressions. We run each test once in the existing version of our service—the one currently in production—and once in the release-candidate version. We compare the results to identify unexpected functionality changes between releases. To ensure robust test coverage, regularly do the following.
- Create unit tests within the implementation class or in a separate test class. Test classes that are annotated with @isTest do not count toward your Apex storage limits. Creating a test class is done like any other class.
- Create test suites to manage your tests.
- Execute unit tests on the server and view the results using Apex test run configurations and the Apex Test Results view.
- Configure debugging output and system logs using Apex test run configurations.
- Single action
- Test to verify that a single record produces the correct, expected result.
- Bulk actions
- Any Apex code, whether a trigger, a class or an extension, may be invoked for 1 to 200 records. You must test not only the single record case, but the bulk cases as well.
- Positive behavior
- Test to verify that the expected behavior occurs through every expected permutation, that is, that the user filled out everything correctly and did not go past the limits.
- Negative behavior
- There are likely limits to your applications, such as not being able to add a future date, not being able to specify a negative amount, and so on. You must test for the negative case and verify that the error messages are correctly produced as well as for the positive, within the limits cases.
- Restricted user
- Test whether a user with restricted access to the sObjects used in your code sees the expected behavior. That is, whether they can run the code or receive error messages.
For more information, see “Understanding Testing in Apex” in the Apex Code Developer Guide.