SF-PD2 Testing, Debugging, and Deployment Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Use HttpCalloutMock to return a 200 response for the happy path, and use Test.setMock with a separate mock returning a 500 response to assert the exception.

  Why this is correct

  Apex forbids real callouts during tests, so Test.setMock with an implementation of HttpCalloutMock supplies a synthetic HttpResponse. One mock instance returning status 200 exercises the parsing path, and a second mock returning status 500 exercises the error branch so the custom exception can be asserted. Both paths are covered without any external network access, which is exactly the required combination.

• ✗

  Use a WebServiceMock implementation, since WebServiceMock is the only interface that supports simulating HTTP responses in tests.

  Why it's wrong here

  WebServiceMock simulates responses for SOAP web service callouts generated from WSDL, not for HTTP callouts issued through the Http and HttpRequest classes. Using it here would not intercept the REST callout and the test would fail with a callout exception. HttpCalloutMock is the correct interface for simulating REST and generic HTTP callouts.

• ✗

  Use Test.setMock with HttpCalloutMock and set the mock's response status to 500 for both the happy path and the error path.

  Why it's wrong here

  Reusing a single mock that always returns status 500 means the happy path never receives a successful response, so the parsing assertions cannot pass and only the exception branch is exercised. The test would not validate the parsing logic at all. Distinct mock behaviour is needed for each path, making this approach incorrect for covering both scenarios.

• ✗

  Use Test.isRunningTest within the service to branch around the callout logic and return hardcoded values.

  Why it's wrong here

  Short-circuiting the callout with Test.isRunningTest bypasses the actual response parsing code, so the test never exercises the logic under test. It also provides no way to simulate a 500 status and assert the exception, because the branch returns hardcoded values instead of a response. This technique hides defects rather than verifying the parsing and error handling behaviour.