When an apex test method attempts to make a web service callout something like the following is logged:

23:11:45.288 (4288851000)|EXCEPTION_THROWN|[116]|System.TypeException: Methods defined as TestMethod do not support Web service callouts, test skipped

23:11:45.288 (4288996000)|METHOD_EXIT|[346]|01p40000000Gykn|XYZ.FooWebService.BasicHttpBinding_IAdBookConnectNS.FooMethod()

23:11:45.289 (4289007000)|METHOD_EXIT|[39]|01p40000000Gy7G|XYZ.FooWebServiceWrapper.fooMethod()

23:11:45.291 (4291299000)|FATAL_ERROR|System.TypeException: Methods defined as TestMethod do not support Web service callouts, test skipped

23:11:45.291 (4291318000)|CODE_UNIT_FINISHED|Test_FooWebServiceWrapper.fooMethodTest

23:11:45.291 (4291326000)|EXECUTION_FINISHED

Not attempting to make the web service callout makes sense, as you don't want irreversible changes occurring every time you run the automated tests. (Plus there is the potential delay due to the callout latency).

I know that I can use Test.isRunningTest() to avoid the callout when testing and return suitable mock data.

However, if the callout is attempted, the only accurate indication that the test case failed is buried in the log file. It doesn't get explicitly marked as failed or skipped.

In addition to the log messages, there is a mismatch between the Tests Run count and the displayed Test Successes, but you would need to be checking for that to pick it up.

Is it possible to force test cases to explicitly fail when a test method attempts a web service callout?

One basic solution I've found is to catch the TypeException and explicitly fail the test method. I tried re-throwing the exception, but there must be some property on it that makes it fail silently. E.g.

try {
    fooWebServiceInstance.FooMethod();
} catch (System.TypeException ex) {
    System.assert(false, ex.getMessage());
}

Attribution to: Daniel Ballinger

Possible Suggestion/Solution #1

If you haven't already, you might want to check out what's coming in Winter '13 in the Support for Testing Callouts section to consider how you might design/refactor things down the road.

My personal preference has been to roll my own mock support, creating a mock mock framework ;) But I think things are going to get much cleaner with the HttpCalloutMock interface.

To your question, I don't know if what your attempting to do is possible. But even if it was, I'm unclear as to why you would really want to do such a thing instead of always preparing mock callout responses to actually test the rest your code in the given execution context. Unless you're dealing with code that isn't in your control, an Eclipse global search for HTTPRequest and proper mock handling throughout is the recipe I'd recommend.

Attribution to: Adam
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/1290