Typically I interface all services. This allows creation and injection of mock services into the ServicesCollection. My Test project will then usually contain several implementations of the interface, allowing me to use whichever is appropriate for a given test. You then create an inject the appropriate items in the TestInitialize or in the TestClass constructor. Your Module should pull dependency services by Interface, so it will get your test instances when you want.
If you look at the source for CFTestRunner, you can see I didn't do a lot of ancillary support beyond the TestMethod and TestInitialize attributes. You could certainly extend it if you need, but the reason it's so thin is because I never actually needed anything else.
You can't really test the direct Module loading because CFTestRunner isn't a SmartClientApplication
so the IModuleInfoStore is never going to get loaded. I suppose you could create a derivative CFTestRunner that is a SmartClientApplication
, which would allow you to create an attribute for your TestClass that would let you return an IModuleInfoStore
.