Derik Whittaker : StructureMap, Agile

StructureMap and Loaded Plugins Gotcha

Derik Whittaker — Fri, 19 Dec 2008 02:33:14 GMT

One of the really great things about the latest release of StructureMap is that I do not need to register objects by default if they follow a standard convention (i.e. if I want to register a controller called ‘AuthorController’ and accessed via ‘AuthorController’ I do not need to do anything, SM is smart enough to map this for me). However, as great as this is, there is one slight issue (may be a bug, do not know need to follow up with Jeremy).

In the Dimecasts codebase I put the logic to register routes for each controller into each controller. I then at startup time I loop though all the controllers and register each route.

The code below is the logic I do for performing this registration

	
	var controllerInstances = ObjectFactory.Model.PluginTypes.Where(x => typeof(BaseController).IsAssignableFrom(x.PluginType));

	foreach (var controllerInstance in controllerInstances) 
	{ 

	var instance = (BaseController)ObjectFactory.GetInstance(controllerInstance.PluginType); 

	instance.RegisterRoutes(RouteTable.Routes); 

	}

All of this works and works well but when i added a new controller to the application and did not manually register it (aka using the convention of configuration feature) I was not able to load the new controller. I was a little stumped at first, but then it downed on me that since i am not pre-registering the controller with StructureMap it may not now how to find it. To test this theory i simply manually registered the controller and bam, all worked.

I thought I would share this incase anyone else had the same issue.

Till next time,

[--- Remember to check out www.dimecasts.net ---]

Using the RhinoAutoMocker that is part of StructureMap 2.5

Derik Whittaker — Sun, 05 Oct 2008 18:58:25 GMT

One of the new features that is part of the next release of StructureMap 2.5 is a AutoMocking Container.

What is an AutoMocking Container, well per Jacob over at Eleutian an AutoMocker is

AutoMockingContainer is simply a IoCContainer with a custom facility and dependency resolver that supplies a Mock (RhinoMock) for any interface that is resolved.

My definition is a little more straight forward and uses simpler word (remember I am a simpleton :))

An AutoMocking container is simply a tool that will inject mock dependencies into your object for you.

What I want to do today is show how an AutoMocking Container can reduce the amount of code/noise from your tests. I am going to first show a tests that simply uses RhinoMocks then that same test that uses the RhinoAutoMocker

Test with only RhinoMocks

[Test]
public void NoAutoMocker()
{
	var mockProvider = MockRepository.GenerateMock<IPersistingRulesProvider>();
        var mockRepository = MockRepository.GenerateMock<ISynchronizationRepository>();
        var mockPersistanceProvider = MockRepository.GenerateMock<IPersistanceProvider>();
        var mockLogger = MockRepository.GenerateMock<ILogger>();

	// Expectations
        mockProvider.Expect(x => x.ExecuteRules(null)).IgnoreArguments().Throw(new Exception("Do not care what this is"));
        mockRepository.Expect(x => x.StartTransaction()).Repeat.Once();
        mockRepository.Expect(x => x.RollbackTransaction()).Repeat.Once();
        mockRepository.Expect( x => x.CommitTransaction() ).Repeat.Never();

	var persitingPipeline = new PersistingPipeline(mockProvider, mockPersistanceProvider, mockRepository, mockLogger);
        var result = persitingPipeline.PersistChanges(new DataSet(), 0, 0, 0);

	Assert.That( result, Is.Not.Empty );

	mockRepository.VerifyAllExpectations();
}

This code above has a bit of noise. Because my object has a dependency on 4 other objects i need to create mocks for each of these. This creates more work and just adds to the test noise.

Test with the RhinoAutoMocker

[Test]
public void WithAutoMocker()
{
	var mockPipeline = new RhinoAutoMocker<PersistingPipeline>();

	mockPipeline.Get<IPersistingRulesProvider>().Expect( x => x.ExecuteRules( null ) ).IgnoreArguments().Throw( new Exception( "Do not care what this is" ) );
	mockPipeline.Get<ISynchronizationRepository>().Expect(x => x.StartTransaction()).Repeat.Once();
        mockPipeline.Get<ISynchronizationRepository>().Expect(x => x.RollbackTransaction()).Repeat.Once();
        mockPipeline.Get<ISynchronizationRepository>().Expect(x => x.CommitTransaction()).Repeat.Never();

	var result = mockPipeline.ClassUnderTest.PersistChanges( new DataSet(), 0, 0, 0 );

	Assert.That( result, Is.Not.Empty );

}

The code above does not require me to create mocks for each of my dependencies, the AutoMocker will do that for me.

Also notice that when I need to set an expectation for a dependencies I can access it via the .Get<>() method.

Till next time,

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

StructureMap 101 Error Gotcha

Derik Whittaker — Sat, 02 Feb 2008 20:48:03 GMT

Today I was putting together a test app for a few presentations I am doing in the coming weeks (announcements on these coming soon). While doing this I kept getting a 101 exception when trying to build an object via StructureMap's ObjectFactory (error information here).

Error message
Assembly {AssemblyNamehere} referenced by an <Assembly> node in StructureMap.config cannot be loaded into the current AppDomain

What did not make sense is that the test project had reference to the assembly that it was complaining about. It turns out that I was not actually using the assembly so it did NOT copy the assembly to the bin directory during compile time. Which I guess makes sense.

So, after pondering what to do, I simply created a 'hack' class that created an instance of an object out of the missing assembly. Now it copied the .dll to the bin directly like I thought it would. I can here you now, why create the 'hack' class. Well, simple, I was not using the assembly directly, but using it via IoC with StructureMap.

So, if you ever get the 101 exception from StructureMap, make sure the assembly is actually being copied to your output (bin) folder like you thought.

Till next time,

Using RhinoMocks with StructureMap to mock expected calls

Derik Whittaker — Tue, 24 Jul 2007 14:32:00 GMT

What do you do when you are writing a test for a piece of code that calls out to an ‘out of your control’ service such as a web service or email server? If you are like most of us, you simply allow your test to make the call and ‘hope’ that the service is up. However, this is really bad. Having your test make calls to a service that is out of your control can lead to ‘spontaneous’ breakages. It also puts dependencies in your test, another bad thing.

If you are using RhinoMocks (could also use NMock, but I like RhinoMocks) and StructureMap (could use any IoC/DI container, but I like StructureMap) it is pretty easy and straight forward to ‘Mock’ out those services.

Quick background on this code.
This test was writing to verify that when a web service is down (IMilesServiceContract) that an email (IEmailer) will be sent. Because I cannot force the service to be down, I have to ‘fake’ it out with Mocks. And because I don’t care that the email actually gets sent I also will fake this out.

Below is the code that will allow you to ‘Mock’ out a web service and them email service

Code Explained

Generating the stubs
Because I don’t want to use the actual concrete classes, I am going to create stubs of them via RhinoMocks

Setting the expectations
Once I have the stubs created, I want to set the expectations on the methods for each of the stubs that I want to be called. I don’t care about the actual parameter values used, so that is why I use the IgnoreArguments method. It is here you set the default return value.

Injecting the stubs into StructureMap
In order for StructureMap to use the stubs, you need to ‘inject’ them in so that when the next call to create the object via the ObjectFactory is called the stubs will be returned.

ReplayAll
This tells the RhinoMocks engine that all setup work is finished and to set the mocking eninge

Few Gotcha’s to look out for

You must set any expectations PRIOR to using the object/stub. Otherwise you will get an exception.
It’s best/easiest to inject interfaces into StructureMap. I have issues when ever I inject concrete classes.

Till next time,

StructureMap Tip: Using Concrete classes as a PluginFamily

Derik Whittaker — Mon, 23 Jul 2007 22:43:00 GMT

Have ever wanted to use a concrete class as both the the PluginFamily and Plugable (information on StructureMap's attributes here) type in StructureMap? I know I have, just today in fact (not the first time, but thought I would post about it this time) I needed to do just this. Why would I want to use a concrete class as both PluginFamily and Plugable type you may ask. Well in this case because I wanted to use DI to inject my configuration class into one of my objects (via constructor injection) and did not think it was worth the effort to create an interface.

Normally if you were use an interface as the PluginFamily and a concrete class as the Plugable, your code would look something like below.

Interface

[PluginFamily("FamilyNameGoesHere")]
public interface IFoo
{

Concrete

[Pluggable("FamilyNameGoeshere")]
public class Foo : IFoo
{

Do have your concrete class act as both you simply combine the two as such

[PluginFamily("FamilyNameGoesHere"), Pluggable("FamilyNameGoeshere")]
public class ConcreateWithNoInterface
{

Keep in mind, that when you do not use interfaces with DI, you are taking away a lot of the power and flexibility that DI provides you. But there are cases from time to time where this situation comes into play.

Till next time,

What I'm Learning

Derik Whittaker — Fri, 08 Jun 2007 22:18:00 GMT

This post is in response to Sam Gentile's post over at code better I'm Learning Rhino Mocks NHibernate StructureMap Policy Injection Blocks Log4Ne t (yea I know, what took so long. Answer, last few apps use the Logging App Block) MonoRail (about to start...(read more)