12

We have a managed package that has executes a HTTP callout from a trigger that calls a future method on the insertion of new records on a particular object. We have a managed package extension that inserts records on the managed package object which invokes a callout through the managed package.

The problem is in test classes in the managed package extension. The test classes are failing because it is inserting these records which cause a callout through the managed package. Normally you would just implement Test.setMock(HttpCalloutMock.class,..) inside the Test.startTest() logic however it is not working.

From what I have read you must implement the Test.setMock method from within the managed package that is actually doing the callout. Has anyone dealt with this before?

Is the solution as simple as building in logic in the managed package trigger to recognize that it is being executed from a managed package extension and to then invoke Test.setMock from the trigger prior to the attempted callout?

For example:

Option 1:

  1. Managed Package Extension inserts new records
  2. Managed Package Extension sets a global variable value inside of the Managed Package
  3. Managed Package trigger fires and looks at the global variable and implements Test.setMock since it was invoked from the managed package extension.

Option 2: Add logic in the trigger to always invoke Test.setMock when it is running in a test context (Test.isRunningTest()).

Thoughts?

1 Answer 1

13

I have something similar in a package I have built - a series of apex classes that make callouts to a third party web service. The expectation is that a customer will then build their own VF controllers to utilize my classes, and the data they return. To get round the issue you raise, I built a globally available method in a class in my managed package that sets the mock interface. So if a customer writes a test class in their own instance that references my code, so long as they call that method in my package, the mock callout is being invoked from within my package, and the callout uses the mock interface/response. I would think it would work the same with an extension package.

2
  • +1 for this, i imagine that what is at play here is namespace isolation, meaning that the mock implementations passed to setMock are scoped to the current namespace (or default namespace for unmanaged). So yes you need to set it from some code running in the namespace you want the Mock to apply to. Which seems reasonable I guess. Nice answer! Commented Oct 16, 2013 at 8:25
  • That's what I figured but wanted to check before modifying and experimenting with our core managed package. Thanks for the quick response.
    – Joe
    Commented Oct 16, 2013 at 13:28

You must log in to answer this question.

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