1

I have a requirement to access the container directly because Prism's IContainerRegistry doesn't provide me the ability to pass parameters through the constructor of an instance I am registering.

However I can't mock IContainerRegistry because I have to call .GetContainer() on it, which is a static extension method.

In short, if I have to access the container directly to do something more complex than IContainerRegistry and IContainerProvider provide in their interfaces and have to get the container directly via .GetContainer(), what is the best way to unit test RegisterTypes(IContainerRegistry) and OnInitialized(IContainerProvider)?

  • I considered passing in a concrete implementation of the IContainerRegistry but this is much less than ideal.
  • I also don't think I can create a wrapper for the extension method since I can't change the signature of RegisterTypes as this is an implementation detail of the Prism library and not my own code.
swirlycurly
  • 11
  • 3
  • `I have a requirement to access the container directly` ... I highly doubt that. You want factories instead, see [this answer](https://stackoverflow.com/questions/39768318/how-better-to-resolve-dependencies-in-object-created-by-factory/39788267#39788267), for instance. The non-mockability of extension methods is used by some as an argument against their use, btw. – Haukinger Feb 14 '23 at 18:54
  • Maybe completely irrelevant to your question, but you DryIoc always allows resolving the IContainer instance (unless it was specifically forbidden by the integration library, e.g. Prism). – dadhi Feb 14 '23 at 21:35
  • 1
    @dadhi It does look like it's possible to resolve the IContainer instance through the constructor which might help me. Thanks! – swirlycurly Feb 15 '23 at 17:53
  • 1
    @Haukinger I might go for refactoring my code into a factory pattern too, that would certainly clean it up a bit. – swirlycurly Feb 15 '23 at 17:53

0 Answers0