3

I'm doing some service calls of which I do not have anything to do with the response. So it's most of like fire and forget thing.

Below is my abstract implementation

class A
{
    public void Setup() 
    {
        //This is the only public method of this class which is called from Scheduled Job
        //This method retrieves all the required using SOQL 

        Request(lstWrapperClass);
    }

    private void Request(List<WrapperClass> lstWrapperClass) 
    {
        //This is a private method and calls the REST API using HTTP Objects.
    }
}

All the examples I came across for HttpCalloutMock is calling some static method which returns HTTPResponse which is generally obvious for most of the cases.

But here in my case, I do not need the response. So I have wrapped it into private method. Also the Class being not Static I cannot use Class.Method() nomenclature to call the method.

So I'd like to know that is it mandatory to write Test Class for Callout Methods?

Provided

  1. I can use Test.isRunningTest() on Request Method so that it prevent sending the mock data to Web Service.

  2. My other code in the class is enough to get more than 75% Coverage.

6

The entire point of unit tests has nothing to do with coverage, but everything to do with avoiding regression bugs. By simply skipping testing, you're actually putting yourself at risk that something will change later that will cause a fatal error, in production, potentially preventing any of your users from doing anything.

For example, a developer might later add a DML statement somewhere, causing the transaction to crash because of "uncommmitted work pending" exceptions. If you let this get in to production, it can literally stop all of your users from being able to do their jobs.

Or, if it's written so well that it just ignores the errors, perhaps your callouts never fire again, and you lose days, weeks, or even months of data as the data loss goes unnoticed.

Do not underestimate the value of valid unit tests. Even if you don't need the response, I presume that you do need your users to keep working without interruption from uncatchable, fatal exceptions. I also presume that you really want your callouts to not fail arbitrarily and without notification.

The typical response class is less than a dozen lines of code anyways. It's taken me longer to argue for the existence of such a class than it'd probably take me to write such a class. Do not get lazy, write the code, make the test pass legitimately. Doing anything less is risky behavior and may very well cause a meltdown later on, usually at the worst opportune moment.

  • when I saw this question I immediately though of your most excellent QueueHttpMock Class. Glad to see your response, and it's another most excellent one! – John Thompson Aug 31 '17 at 17:11
5

Yes, implementing a mock should be considered necessary. If you do not care about the response, it is quite simple:

@IsTest public class MyMock implements HttpMock
{
    public HttpResponse respond(HttpRequest request) { return null; }
}

My advice, never use Test.isRunningTest() unless there is no other way to accomplish what you desire.

At least in this way, you can verify a callout is made.

Test.startTest();
    new A().setup();
    Integer callouts = Limits.getCallouts();
Test.stopTest();

system.assertEquals(1, callouts, 'A callout should be made');
3

The reason to implement HttpCalloutMock, beyond being able to test the response(s), is for Salesforce to be able to have something to call when your test code reaches the callout itself.

If your test gets to the callout, and you don't have a mock for it, the test will attempt to actually make the callout (which will result in an exception).

Provided that your unit tests already give you 75% coverage, wrapping your callout in if(!Test.isRunningTest()) would work in place of implementing HttpCalloutMock. I couldn't recommend that approach except for fire-and-forget situations like the one you have.

Even with a fire-and-forget callout, there can still be some merit in creating a mock. In an HttpCalloutMock, you can also throw exceptions. If your callout is in a try/catch block (which it probably should be), it would be a good idea to test that behavior and HttpCalloutMock is how you would do it.

-1

I don't think Mock Callout is necessary. You can write down your own custom class and call it when test is running, by just check the condition(Test.isRunningTest). It will provide you more flexibility to reach out to your maximum code coverage and maximum use case testing. Thanks

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.