2

I have to test IoC Service implemented in MyMobileApp.MyService.Module.

At the moment my unit test project MyMobileApp.MyService.Module.Tests has referenced on IoC Module MyMobileApp.MyService.Module

CFTestRunner is used for debugging and Visual Studio test runner can be also used to run test with output to GUI window(???)

IMHO this architecture has drawbacks:

  • Services must be initialized manually in [TestInitialize]:

try { var module = new Module(); // Drawback: what if 2 services should be used? module.AddServices(); } catch (Exception) // Services must be added only once { // In TestInitialize // ClassInitilaize method is not executed if unit test is running under CFTestRunner??? }

this.myService = RootWorkItem.Services.Get();

  • To test another service implementation I should change reference and recompile test project

Therefore I have some improvements ideas:

  • Is it good to use testable version of ProfileCatalog to allow IoC container add testing services automatically? How can this ProfileCatalog correctly deployed on devcie/emulator?

  • Is it good to use inject services in test class (if it possible)?

Also where can I found sample code/project(s)/articles with good testing patterns - I mean testing IoC services

hellboy
  • 1,567
  • 6
  • 21
  • 54
  • Have you looked into Mocking frameworks such as Moq? – Simon Whitehead Feb 28 '14 at 12:12
  • .NET CF does not suppport Reflection.Emit which is needed to generate the proxies.. – hellboy Feb 28 '14 at 12:42
  • What about stubbing them out yourself? Your question seems to be related to having dependencies injecting into your actual code under test... which you shouldn't be doing during unit tests, as they will cause your tests to take a very long time to execute. That's more of an integration test at build time. – Simon Whitehead Feb 28 '14 at 12:46

1 Answers1

1

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.

ctacke
  • 66,480
  • 18
  • 94
  • 155