Testing Autofac Configuration

[Steve U]

Has anyone set up unit tests (or whatever you would like to call them)
to verify that the autofac config (be it the XML based or fluent API)
can resolve types etc?

I am thinking along these kind of lines:
http://stackoverflow.com/questions/731616/castle-windsor-how-to-test-that-all-registered-components-are-resolvable

[Rinat Abdullin]

Hi Steve,

I'm using this kind of tests (functional/synthetic) on a regular
basis. There are a few common scenarios:

1. Simple sanity checks, when same Autofac modules are used for
production purposes and in setting up test-fixtures for the repository
tests (such fixtures use IoC internally to keep code really simple).
If something is wrong with the IoC setup, then related fixtures would
not even start.

2. Smoke tests, when a few related Autofac modules are loaded together
in a test fixture (missing dependencies are generally resolved by mock
container) and then a few complex interactions are fired. Some sanity
checks and assertions are launched along the process and after it.
This helps to catch a few bugs in multi-threading or scheduling type
of logic.

3. Full stress tests (are usually manually launched from an executable
that is instrumented with statistics capturing), where multiple
subsystems are wired together with Autofac. For example, we could drop
WCF layer and wire client-side functionality directly to the server-
side code with full paging, batching and auth logic; latter could
wired directly to the DAL layer working with in-memory or
prepopulated database. Adding a few threads (i.e. 20) doing resource
intensive operations would give some indication how the entire
infrastructure deals with dead-locks and performance bottlenecks.

That's just a few scenarios from the top of my head. You don't
necessarily need Autofac for these, but using it makes everything a
pleasure.

Best regards,
Rinat Abdullin

http://abdullin.com

On Aug 24, 9:12 pm, Steve U <downcha...@gmail.com> wrote:
> Has anyone set up unit tests (or whatever you would like to call them)
> to verify that the autofac config (be it the XML based or fluent API)
> can resolve types etc?
>

> I am thinking along these kind of lines:http://stackoverflow.com/questions/731616/castle-windsor-how-to-test-...

[Steve U]

Hi Rinat,

Thanks for your reply. The main problem I am trying to resolve here is
where we have a core library and several clients and how to identify
if the configuration in a client project is broken by a core library
change. For example, there might be a class in the library that has
one a constructor with one parameter and the autofac configurations in
each of the clients can bind to that constructor. However, some
refactoring is done to add a parameter to that constructor. Now when a
client tries to resolve that instance it breaks.

I know we could always add an overloaded constructor or use property
injection, but that isn't necessarily the right thing to do.

Has anyone got any code samples of doing such a thing with Autofac?

Thanks
Steve

[Rinat Abdullin]

The only way that comes to my mind is to encapsulate component
registration functionality in autofac modules and then reuse these
modules in synthetic tests that use environment similar to the client
usage scenarios.

Additionally, if you have components that are shared between multiple
VS solutions, including a project-wide validation build to your
continuous integration routine, might be a good idea. It definitely
works for me and helps to discover a lot of dormant issues (including
resolution problems).

[IMHO]
Using property setters and multiple constructors is not an advised
practice while building systems that don't require extreme
extensibility. It just adds too much of a complexity to the design and
code.

When a component has a single point of control entry (that's a single
constructor and no setters), then everything becomes more
deterministic and reasonable.
[/IMHO]

Best regards,
Rinat Abdullin

http://abdullin.com