3

I have a test class containing several WebServiceMock implementors. He looks like this:

@isTest private class MyTestClass {

    public class ValidateMock implements WebServiceMock {
        public void doInvoke(Object stub, Object request, Map<String, Object> response, String endpoint, String soapAction, String requestName, String responseNS, String responseName, String responseType) {
            //...
        }
    }

    static testMethod void coverRetrieve() {
        Test.setMock(WebServiceMock.class, new ValidateMock());
        //...
        System.assert(result instanceof Object);
    }
}

But as I create more WebServiceMocks, I see the Code Coverage metrics for my org going south!

Of course, I tried to annotate the WebServiceMock inner classes with @isTest but will get:

Only static top-level class methods can be test methods

(Which they should be, anyway, as inner classes of an @IsTest annotated class)

Currently I think my options are:

  1. write a "Test Test" method that invokes all the mocks just to bump the coverage,

  2. proliferate all the WebServiceMock classes as top-level, then add the @isTest annotation,

How else could I prevent these test inner classes being seen by the code coverage metrics?

2
  • I really think your second option is the best. That's the way I usually go. You may end up with a lot of files, but that seems better than cluttering up the code with "test test" methods. Commented Jan 21, 2014 at 12:48
  • Wonder if this fixed known issue is related? In that issue the inner class is in the code being tested and not the unit test code, but could be the same. Could be a regression. Also found this question. Commented Jan 21, 2014 at 13:00

1 Answer 1

1

Found a combination that works:

  • use @TestVisible and private visibility

This excludes it from code coverage metrics.

1
  • sometimes I use a constructor with args in my mock inner class so I don't have to write many mocks - rather, one mock adjusts its results using the 'settings' passed into the constructor. Another approach is to pass in a string of a static resource that contains the results you want from the callout so you only need one mock class and all the variability of response comes from staticresources
    – cropredy
    Commented Dec 20, 2014 at 1:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .