in Search

Do you Twitter? Follow us @devlicious

Derik Whittaker

Thoughts on Software Development, .Net, OOP, Design Patterns and all things cool

IOC(SM):MOC(RM):TDD(NU):SCC(Svn):ORM(L2S):XPP(-):XPP(+):DDD(T+)

Testing your IoC Bindings

One thing I like to do when I am using a IoC (Inversion of Control) container is to create simple test that ensure that my objects have been wired up correctly and can be created via the IoC container.

I know this may seem like overkill, but I feel that by having my IoC bindings covered by tests I am covering all my bases.

So, what does testing my bindings do for me

Allows me to know if my object is configured correctly
By having these tests I will know immediately if I have somehow broken my IoC bindings glue (yes, glue is the technical term in this case).

It is not hard to phantom that when making changes to your IoC bindings logic (either via config files or via inline code) you can mistakenly break something. Having these tests provides me immediate feedback if this were to happen.
Allows me to know if my objects dependencies are configured correctly
Setting up the wiring for your main object is only half the battle. When using an IoC container many time you are going to have that container do some sort of Constructor Injection of your dependencies.

By having tests that simply create my object with IoC I will find out immediately if one of my dependency objects is not wired up. This scenario is pretty common and having this test can save you some headaches.

Here is the test code I use for my IoC bindings tests:

[Test]
public void CanCreateViaDI()
{
var iocObject = ObjectFactory.GetInstance< YourObjectHere >();
Assert.That( iocObject, Is.Not.Null );

}

Hope this helps someone.

Till next time,

[----- Remember to check out DimeCasts.Net -----]

Published Sep 10 2008, 06:53 AM by Derik Whittaker

Filed under: Development, TDD, Best Practice

Comments

Dew Drop - September 10, 2008 | Alvin Ashcraft's Morning Dew said:

Pingback from Dew Drop - September 10, 2008 | Alvin Ashcraft's Morning Dew

# September 10, 2008 9:12 AM

Scott Parker said:

Does StructureMap actually return null like that? My experience when I've screwed up my bindings is that I've gotten an exception at some point.

Of course, now that I think about it, usually my mismatches have been related to public classes relying on internal components in their constructors, which generates a framework exception, not a StructureMap exception.

Anyway, good thoughts. Looking forward to see what jdn has to say on the subject as well.

-Scott

# September 10, 2008 10:23 AM

Jeremy D. Miller said:

StructureMap will blow up with StructureMapException if it doesn't know what to do with "YourObjectHere"

Derik,

If all you want is a quck sanity check, and you're using 2.5, do:

// set up the container

ObjectFactory.AssertConfigurationIsValid();

and that will find all missing ctor values, properties, try to build everything it knows about, and run all environment tests

# September 10, 2008 10:56 AM

Derik Whittaker said:

@Jeremy,

Yea i know it will throw an exception for some reason i still feel better having that assert.

However, i did not know there was the AssertConfigurationIsValid or did not pay any attention. I will use that going forward.

Thanks,

# September 10, 2008 10:58 AM

Matt Hinze said:

Yikes. That is good to know, Jeremy. This is actually a desirable test though. We have a ton of controllers and subcontrollers and to assert that they are registered in the container is a good fast fail before we get a YSOD. I will request this feature...

# September 10, 2008 12:02 PM

2008 September 11 - Links for today « My (almost) Daily Links said:

Pingback from 2008 September 11 - Links for today « My (almost) Daily Links

# September 11, 2008 1:02 AM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?

Enter the numbers above:

Add

About Derik Whittaker

Derik is a .Net Developer/Architect specializing in WinForms working out the northern suburbs of Chicago. He is also believer and advocate for Agile development including SCRUM, TDD, CI, etc.

When Derik is not writing code he can be found spending time with his wife and young son, climbing on his bouldering wall, watching sports (mostly baseball), and generally vegging out.