Theory behind setMock in the Application factories
rygramer opened this issue · comments
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?
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?
@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 😀
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.