Unit Tests in Apex
Testing Apex code consists of writing and executing unit tests. Unit tests are special methods written to exercise the functionality of your code. The goal of testing is to write unit tests that execute as many lines as possible of the target code. The number of lines of code executed during a test is called test coverage and is expressed as a percentage of the total lines of code. Unit tests also typically perform some pretest preparation, such as creating sample data, and posttest verification of results.
Test Methods
Test methods are static Apex code methods, annotated with @isTest. They are written within an outer class, also annotated with @isTest. Tests are subject to the same governor limits as all Apex code, but every test method is completely independent for the purposes of limit tracking, not cumulative. Also, test classes are not counted against the code size limit for a Force.com organization.
A test is considered successful if its method is executed without encountering an uncaught exception. A common testing pattern is to make a series of assertions about the target code’s state using the built-in method System.assert. The argument of assert is a Boolean expression. If it evaluates to true, the program continues; otherwise, a System.Exception is thrown and causes the test to fail.
Listing 4.41 shows a simple test method. It asserts two statements. The second is false, so the test always fails.
Listing 4.41 Test Method
@isTest static void negativeTest() { Integer i = 2 + 2; System.assert(i == 4); System.assert(i / 2 == 1); }
Rather than adding two numbers together, most unit tests perform substantial operations in one or more other classes. Sometimes it’s necessary to examine the contents of a private variable or invoke a protected method from a test. Rather than relaxing the access modifiers of the code to make them visible to tests, annotate the code you are testing with @TestVisible. This annotation provides your test code with privileged access but otherwise preserves the access modifiers in your code.
Test Data
With the exception of users and profiles, tests do not have access to the data in the Force.com database. You can annotate a class or method with @isTest(SeeAllData=true) to make the organization’s data visible to tests, but this is not a best practice. The recommended approach is for tests to create their own temporary test data. All database modifications occurring during execution of a test method are automatically rolled back after the method is completed. Create your own test data in a setup phase before your tests are executed, and limit your assertions to that test data.
Running Tests
All tests are automatically executed when migrating code to a production environment, even unchanged and existing tests not included in the migration. Tests can and should be executed manually throughout the development process. Three ways to run tests are described in the following list:
- The Force.com native user interface includes a test runner. In the App Setup area, click Develop, Apex Classes, and then click the Run All Tests button.
- In the Force.com IDE, right-click an Apex class containing test methods and select Force.com, Run Tests.
From Developer Console, click the Tests tab and the New Run button. Select the tests to include, and click the Run button. Alternatively, right-click on the Classes folder in Eclipse and select Force.com, Run Tests to execute all tests in your organization. Figure 4.9 shows Developer Console after running a test.
Figure 4.9 Viewing test results in Developer Console