Mock Testing for Callouts

Mock Testing for Callouts in Salesforce – A Complete Guide for Platform Developer 1 Exam

Introduction

When building Salesforce applications, you will frequently need to integrate with external systems using HTTP callouts or web service callouts. Testing these callouts presents a unique challenge: Salesforce does not allow real HTTP callouts during test execution. This is where mock testing for callouts becomes essential. Understanding this topic is critical for the Salesforce Platform Developer 1 certification exam.

Why Is Mock Testing for Callouts Important?

Mock testing for callouts is important for several reasons:

1. Salesforce Governor Limits: Salesforce explicitly prevents test methods from making real HTTP callouts. If your code performs a callout inside a test without a mock, the test will fail with a System.CalloutException.

2. Test Isolation: Tests must be self-contained and not depend on the availability or response of an external service. Mock testing ensures your tests are reliable and repeatable regardless of the external system's status.

3. Code Coverage Requirements: To deploy Apex code, you must achieve at least 75% code coverage. If your code includes callout logic, you must use mocks to cover those lines.

4. Best Practices: Mock testing aligns with software engineering best practices by separating your unit tests from external dependencies, making tests faster and more predictable.

What Is Mock Testing for Callouts?

Mock testing for callouts is a technique where you simulate (or "mock") the response from an external web service so that your Apex test methods can execute callout code without actually contacting the external endpoint.

Salesforce provides two primary interfaces for this purpose:

1. HttpCalloutMock – Used to mock HTTP callouts (REST-based callouts using HttpRequest and HttpResponse).

2. WebServiceMock – Used to mock SOAP-based web service callouts (those generated from WSDL imports).

The core idea is simple: you create a class that implements one of these interfaces, define the fake response that should be returned, and then tell Salesforce to use that mock class during your test execution.

How Does It Work? (Step-by-Step)

Mocking HTTP Callouts (REST)

Step 1: Create a Mock Class
Create a class that implements the HttpCalloutMock interface. This interface requires you to implement a single method: respond(HttpRequest req). In this method, you construct and return a fake HttpResponse.

Example:
@isTest
global class MockHttpResponseGenerator implements HttpCalloutMock {
    global HTTPResponse respond(HTTPRequest req) {
        HttpResponse res = new HttpResponse();
        res.setHeader('Content-Type', 'application/json');
        res.setBody('{"status":"success","id":"12345"}');
        res.setStatusCode(200);
        return res;
    }
}

Step 2: Use Test.setMock() in Your Test Method
In your test method, call Test.setMock() before invoking the code that performs the callout. This tells the Salesforce test framework to intercept the callout and use your mock class instead.

Example:
@isTest
static void testCallout() {
    Test.setMock(HttpCalloutMock.class, new MockHttpResponseGenerator());
    // Call the method that performs the HTTP callout
    String result = MyCalloutClass.makeCallout();
    System.assertEquals('success', result);
}

Step 3: The Test Executes Without a Real Callout
When the code under test performs the HTTP callout, the Salesforce framework routes the request to your mock class's respond() method. The fake response is returned, and your code continues as if a real callout occurred.

Mocking SOAP Web Service Callouts

For SOAP-based callouts:

1. Create a class that implements the WebServiceMock interface.
2. Implement the doInvoke() method, which sets the response object with the desired fake data.
3. In the test method, call Test.setMock(WebServiceMock.class, new YourWebServiceMockClass()).

Using StaticResource for Mock Responses

Salesforce also provides an alternative approach using StaticResource-based mocking with the StaticResourceCalloutMock and MultiStaticResourceCalloutMock classes:

- StaticResourceCalloutMock: Allows you to store the response body in a Static Resource file and reference it in your mock. This is useful for large or complex response bodies.

- MultiStaticResourceCalloutMock: Allows you to map different endpoints to different Static Resource files, enabling you to mock multiple callouts with distinct responses in a single test.

Example using StaticResourceCalloutMock:
@isTest
static void testWithStaticResource() {
    StaticResourceCalloutMock mock = new StaticResourceCalloutMock();
    mock.setStaticResource('MyResponseResource');
    mock.setStatusCode(200);
    mock.setHeader('Content-Type', 'application/json');
    Test.setMock(HttpCalloutMock.class, mock);
    // Invoke the callout code
}

Key Concepts to Remember

- Test.setMock() is the critical method that activates mock behavior in tests. Without it, callout code cannot be tested.
- The mock class must be annotated with @isTest or be a global/public class accessible in the test context.
- The HttpCalloutMock interface is for REST (HTTP) callouts; WebServiceMock is for SOAP callouts.
- You cannot mix DML operations and callouts in the same test transaction without using Test.startTest() and Test.stopTest() to separate them. This is because of the restriction that DML and callouts cannot coexist in the same execution context.
- Test.startTest() and Test.stopTest() help reset governor limits and can help separate DML from callout execution within a test.
- Mock responses are completely under your control — you define status codes, headers, and body content, enabling you to test success scenarios, error handling, and edge cases.

Common Exam Scenarios

The Platform Developer 1 exam may present scenarios such as:

1. A developer needs to write a test for a method that makes an HTTP callout. What must the developer do? — The answer involves implementing HttpCalloutMock and using Test.setMock().

2. A test class is failing with a CalloutException. What is the likely cause? — The developer forgot to use Test.setMock() before invoking the callout code.

3. Which interface should a developer implement to test a SOAP-based web service callout? — WebServiceMock.

4. A developer has DML statements before a callout in a test. What should they do? — Wrap the callout invocation between Test.startTest() and Test.stopTest() to create a new execution context.

5. How can a developer test multiple callout endpoints with different responses? — Use MultiStaticResourceCalloutMock or implement logic inside the mock's respond() method to return different responses based on the endpoint.

Exam Tips: Answering Questions on Mock Testing for Callouts

1. Always look for Test.setMock(): If an exam question involves testing callout code, the correct answer almost always involves Test.setMock(). If an answer choice does not include this method, it is likely incorrect.

2. Know the two interfaces: Distinguish between HttpCalloutMock (for REST/HTTP callouts) and WebServiceMock (for SOAP callouts). The exam may try to trick you by swapping them.

3. Remember that real callouts are never allowed in tests: Any answer suggesting that a test can make a real HTTP callout is wrong. Salesforce enforces this restriction strictly.

4. Watch for DML + Callout conflicts: If a question mentions DML operations and callouts in the same test, the solution likely involves Test.startTest() and Test.stopTest() to separate the execution contexts.

5. Pay attention to the method signature of respond(): The respond(HttpRequest req) method receives the request object, which allows your mock to inspect the request and return different responses. This is a subtle detail the exam may test.

6. StaticResource-based mocks are valid: Don't dismiss answer choices that use StaticResourceCalloutMock or MultiStaticResourceCalloutMock. These are legitimate, built-in Salesforce approaches.

7. The mock class can contain assertions too: Inside the respond() method, you can verify that the outgoing request is constructed correctly (e.g., checking the endpoint URL, headers, or body). The exam may reference this pattern.

8. Eliminate wrong answers systematically: If you see options like "use @future to make the callout" or "use SeeAllData=true to allow callouts," these are incorrect. Mock testing is the only supported approach for testing callouts in Apex tests.

9. Understand the flow: Test method → Test.setMock() → invoke code → code makes callout → framework intercepts → mock's respond() returns fake response → code processes fake response → assertions validate behavior. Having this mental model helps you reason through any question.

10. Practice writing mock classes: The best way to solidify your understanding is to actually write and run mock callout tests in a Salesforce developer org. Hands-on practice makes these concepts intuitive during the exam.

Summary

Mock testing for callouts is a fundamental Salesforce development concept that ensures your integration code can be properly tested without relying on external services. By implementing HttpCalloutMock or WebServiceMock and using Test.setMock(), you create predictable, reliable tests that satisfy Salesforce's code coverage requirements and follow best practices. For the Platform Developer 1 exam, focus on understanding when and how to use these interfaces, the role of Test.setMock(), and how to handle common scenarios involving DML and callout separation.