function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
SennahSennah 

Testing webservice call out fails, worked yesterday

Hi community,

 

I hope someone can help with this: I am running a simple test for webservice callouts. It worked just fine yesterday. With no code changed it won't work today. This is really running me crazy.

 

The test method is really simple. It first inserts two objects and then runs the real test:

 

test.startTest();
ZendeskWebcall.customerLicensesToExpire();
test.stopTest();

 

 The tests debug log says the following:

 

 

11:46:24.569|METHOD_ENTRY|[46,19]|System.Http.send(System.HttpRequest)
11:46:24.569|EXCEPTION_THROWN|[46,19]|System.TypeException: Methods defined as TestMethod do not support Web service callouts, test skipped
11:46:24.569|METHOD_EXIT|[46,19]|send(APEX_OBJECT)
11:46:24.569|METHOD_EXIT|[83,7]|sendNotification(String)
11:46:24.569|METHOD_EXIT|[25,13]|customerLicensesToExpire()
11:46:24.569|FATAL_ERROR|System.TypeException: Methods defined as TestMethod do not support Web service callouts, test skipped

 

 The message itself is of course correct; A TestMethod should not make a real call. But why does it exit with FATAL ERROR and don't even continue to stopTest()?

My first thought was that
customerLicensesToExpire()

 

 

 was defined as test method by erro. But it is course not.

 

Any hints?

 

 

rungerrunger

The test is not failing.  The test does end there, because, as the message says, it's skipping the rest of the test (which will result in a rollback, so there's no point in continuing to test.stopTest()).  However, it doesn't show up in your results page as a failure.

 

It arguably should not be saying FATAL_ERROR in the log, but that's harmless.

SennahSennah

runger,

 

you are quite right. It does not show up as a failure. 

But how can I test if my callout works properly, when the test skips. I usually would make an assert after calling the method, to make sure the  callout has been invoked.

 

I had that assertEquals in my code working yesterday. The problem today is, as we discussed, the test skips and don't continue to the next line.

 

Hannes

rungerrunger

I'm confused.  You agree that the test should be skipped, because callouts won't work in a test context.  However, you're expecting to be able to assert that your callout worked?


What am I missing here?

SennahSennah

I expect the callout to be skipped (i.e. re-directed to /dev/null ;) ) but the method to continue.

I mean, how would you test your callout method when the test exits. It's the same as with testing email handling. It invokes the email method but does not actually send out the email.

SennahSennah

At least, I've found out how to process the test.

 

The solution lies in the try/catch clause where I am calling the http method:

 

 

try { res = http.send(req); //} catch(System.CalloutException e) { <-- don't work } catch(System.Exception e) { <-- works! System.debug('Callout error: '+ e); }

 

 Somehow getting the specialized exception produced the error.

 

Not sure if this is a bug or expected behaviour or something between there and just a not-so-good debug output.

 

 

rungerrunger
This is expected behavior.  So far as I know, the behavior has not changed, just the way we log it.