Write Tests for an Extension Provider

Writing tests for an extension provider is an essential step in the development process. These tests ensure that the functionality of the extension class is working as intended and that any changes made to the class do not break existing functionality. It is a best practice to write tests before writing the actual code to have a clear understanding of the requirements and to have a reliable set of tests in place to verify that the code is working correctly.

In this guide, we describe the process of creating tests for extension providers.

Testing code coverage is a measure of how much of the Apex code in your org has been executed by your test methods. You are required to have at least 75% code coverage for your Apex classes and triggers. When you run your test methods, Salesforce calculates the code coverage and displays it in the Developer Console and the Apex Test Execution page.

Refer to Testing and Code Coverage for more information.

Consider the following base Apex class and extension provider class.

When testing an Apex class that interacts with the database, you can use test data to set up the test context and assert that the class is behaving as expected. Here's an example of an Apex test class that tests an Apex class that interacts with the database.

To verify the test data is not persistent, we can create another test like the following.

Refer to the Understanding Test Data for more information.

Mocking HTTP callout is a feature in Apex that allows you to simulate an HTTP callout in a test method, without actually calling an external service. Mocking the callout is useful for testing Apex code that makes HTTP callouts because it allows you to test the code in isolation, without depending on the availability or behavior of the external service.

Refer to Testing HTTP Callouts by Implementing the HttpCalloutMock Interface for more information.

Refer to Mock the Base Apex Class for more information.

Governor limits are a set of limits enforced by Salesforce to ensure that Apex code doesn't consume too many resources. In an Apex test class, you can use the Test.startTest() and Test.stopTest() methods to set an isolated environment between them so that you can see how your code behaves under different conditions. The Test.startTest() and Test.stopTest() methods also reset side governor limits between them, which are independent of the limits outside of it. Here's an example of how you can observe governor limits in the test:

In this example, the test class starts the test environment using the Test.startTest() method and the code that you want to test goes in between the start and stop test methods. Then, the test class stops the test environment using the Test.stopTest() method.

Refer to Using Limits, startTest, and stopTest for more information.

After that, the test class checks the governor limits. The Limits.getQueries() method returns the number of SOQL queries executed within the test method’s pairs. You can use other methods to check governor limits, including Limits.getCpuTime() and Limits.getLimitContexts().

Refer to Apex Governor Limits for more information.

A read-only class is a class that only performs read operations, such as queries, but does not modify the data. To guarantee that your extension provider class is executed in read-only mode, write a test that checks the DML operation for your Apex class.

Now you that you have written your test code, you can run it on your extension provider class and make any necessary changes.

Refer to Exception Statements for more information.