Theory behind setMock in the Application factories

[rygramer]

When you call the setMock method in the Application factories, it turns around and instantiates a new force-di injector, which ultimately calls replaceBindingsWith. This replaces the binding in the current list of bindings with the mock instance. But if there is no binding configured (ie there’s no custom metadata record), the mock isn’t set.

I would assume that if I call setMock, the current binding would be replaced if there is a binding configured OR if a binding doesn’t exist, the mock would be set as the binding. Basically, no matter what, a call to setMock results in the mock that is passed in being set as the binding used by force-di.

What am I missing?

[ImJohnMDaniel]

G'day @rygramer

Thanks for reaching out.

Well, if you don't have a default binding configuration, then there is no dependency injection that is occurring for your application in normal operations. If that is the case, then I don't see a point in trying to set up a mock for something that doesn't exist normally.

Can you elaborate on your use case please?

[rygramer]

@ImJohnMDaniel - so sorry for the delay!

Taking at4dx-sample-code as an example: the common package over there has a method on AccountsSelector called selectByName. I'd like to move this method definition to an interface -- ISelectAcountsByName extends IApplicationSObjectSelector, and have AccountsSelector implement it.

ISelectAccountsByName would be individually packaged (so only a single interface in this package). The common package would depend on it. And any other package that needs this selector method would depend on it. So, in this sense, no packages would actually depend on the common package; all packages depend on these "microservice" interface packages.

Now to the replaceBindingsWith from force-di problem: the selector custom metadata definition lives in the common package. Because other packages aren't dependent on the common package, but rather the intermediary microservice package(s), there are no bindings to actually replace during package build tests.

To solve this, I've duplicated the custom metadata mappings as unpackagedMetadata. Works fine! Just duplicative and confusing for devs.

That's a lot to unpack! Let me know if anything is unclear 😀

[ImJohnMDaniel]

Well, the intent was that the Sales, Service, and Marketing "packages" would all depend on the "Common" package. Granted, in the same code project, it is difficult to represent that idea as all of the code exists in the same GIT repo, but that is the example.

So, the "Common" package would serve as the layer that you are referring to as a the "microservice interface package"..... that is assuming that I am understanding your example correctly.

Also, I am happy to get on a call to discuss this concept further if that would help.