Apex test class using JobScience Job Location object

Question

I've written an Apex job that makes use of some JobScience objects. I'm having a problem with creating a new JobScience Job Location object in an Apex test class. I can successfully create and insert the object, but what happens is there is a process that is called from within the managed package for that insert (trigger or otherwise) that attempts to make a callout to their Geolocation service which is a violation in Apex test classes (no callouts allowed). My guess is because the object contains a Geolocation field. I've tried to mock this callout (which I really can't do because it's in their namespace), I've tried to pre-populate the Geolocation field (just Lat and Lng) via a call to a mock Geolocation service, and verified that the values are indeed there, to see if that would prevent their callout from happening, but that didn't work either.

Has anyone ever run into this specific case with JobScience Job Locations inside of test classes (or anything similar when working with other managed objects)? I have no idea how to work around this and, unfortunately, Job Location is a required object for this test. We've reached out to their support but they are not able to help us (for a myriad of reasons, we'll just leave it at that).

Thanks for any an all help!

Answer 1

The general approach for mocking otherwise non-creatable SObjects depends on the scope you need the mocked objects for:

Option 1 - Code-Under-Test merely needs to fetch the SObjects

Preconditions

• No DML required against the fetched objects

Solution

• Wrap the fetch of the Sobjects into a Selector class (e.g. JobsSelector )
• Dependency inject a mock implementation of the selector class into the code-under-test. ApexMocks is useful to do this but there are other techniques as well by passing in a mock implementation to the code-under-test's selector similar to the way HttpCalloutMock is used.
• Have the mock selector class return mocked SObjects using the JSON.deserialize technique. A nice library that does this is SObject_Fabricator by @mattaddy

Option 2 - Code-Under-Test needs to fetch and update the SObjects

Preconditions

• DML required against the fetched objects

Solution

• Wrap the fetch of the Sobjects into a Selector class (e.g. JobsSelector ).
• Wrap the DML statements into a new class using the Unit Of Work pattern such as in Trailhead Unit of Work Pattern. In effect, you registerNew(..) or registerDirty(..) Sobjects that are passed to the unit of work object.
• Dependency inject a mock implementation of the selector class and unit of work class into the code-under-test. ApexMocks is again especially useful to do this.
• Have the mock selector class return mocked SObjects using the JSON.deserialize technique. A nice library that does this is SObject_Fabricator by @mattaddy
• Have the unit test verify that your calls to registerNew and registerDirty are what you expect to have happen (i.e., you constructed/modified the proper sobjects -- note no DML is actually done as you have mocked the unit of work)

Notes

1. ApexMocks is a layer around the StubAPI and adheres to the Mockito library as used in Java. There is a learning curve here but there are resources on the GitHub Readme as well as here on Stackexchange.