Village Wisdom:

-          We use constructor dependency injection (and sometimes properties) because it’s important to expose your dependencies…

-          … so that callers who aren’t using IoC (ahem  tests) can easily work with the test in isolation by using mocks and not having to involve an IoC container…

-          … and so it behooves us to keep the number of dependencies in a class down to a minimum to keep tests from getting too complicated…

-          … which also forces us to battle between too-many-dependencies and dependencies-that-do-too-much.

Basically, it seems like we make a lot of choices based on writing tests and the fact that our tests don’t use IoC (to keep things less complicated, we tell ourselves).

Now, I happen to buy into this, and it has worked well.  But… what if… we started allowing an IoC container to creep into our test playground, also (of course with something handy like AMC to populate the container with the more mundane stuff).

This opens up a whole new style of dependency management, IMHO.  What if we designed classes to _require_ some form of IoC container.  What if passing every dependency into the c’tor or properties isn’t the best way (every time)?

Bellware (and others) have talked about the various forms of dependencies (opaque, etc) and the one where a given class goes out and gets all its dependencies from the container itself (as opposed to having them injected) is ‘close’ and ‘not horrible’, but not perfect.

What if we require you to pass in a single ‘dependency resolver’ interface (which is basically the IoC container) into the c’tor from which the dependencies are gathered?

“What does this gain us?” you may ask.  Well, it prevents your tests from having to know about all the dependencies in a given class. It makes tests less brittle as you can add and remove dependencies without having to change as many tests – or changing the tests dramatically. It requires less setup and less expectation management just to get to some interesting part to test.  The AMC, container, and the class-under-test could work out themselves what needs to be mocked in order to satisfy the dependencies of the class and your test can interact only with the mocks you need to interact with in order to pass

the test.

I haven’t had a chance to put any of this to code (yet), but this occurred to me at the TDD CodingDojo today (more about that later) and I thought it might work.  I’ll try to whip up some examples of what I’m talking about and I may find that it’s not worth doing, but I’m willing to bet that this may address some of the friction of what to mock, how many, what expectations, etc.

Thoughts?

-Chad